Jonathan Malek said:
Daniel,
Correct me if I am wrong, but there is no polymorphic way to access static
methods in C# because C# doesn't support virtual static methods. Other
languages do (Delphi, for one). In other words, the most important argument
for not having abstract statics is that C# doesn't support them. So, I
figure I am missing something.
I have read quite a bit on this topic in other lists (the comp.std.c++
list had what seems like a semi-annual celebration on the issue for several
years), trying to understand what the issue is. I suppose I don't quite see
the messy aspect of it all. Everyone raises the same issue--"virtual
static?? Why ever would you want to do such a thing? Oh I see--well, you
know, you could do that this way, or that way..." That's not really an
answer. It can be done, it solves a particular design problem (I've written
one up below that I feel can only be solved this way--or, as you mention,
with contract-enforced attributes), and other languages have shown that.
So, is there something beneath it all, say in the CIL/CLS/CTS/CLR that
prohibits such a thing? Better question--is it possible to introduce
CTS-compliant virtual statics? I suppose if the answer to that is no, then
it is pointless wondering why C# doesn't support them.
Well, the primary problem is in cases like this, assume Base has a virtual
static called StaticMethod and Derived is derived from Base.
Base b = new Derived();
//this really isn't legal, because you can't access a static method via a
//reference(nor should you be able to, imho).
//even if you could, which StaticMethod is being called here? cases could be
//made that it should be Base.StaticMethod() or Derived.StaticMethod()
//if Derived.StaticMethod() is proper, you could end up with unpredictable
//behaviour here.
b.StaticMethod();
How exactly do you execute the static method without exposing statics (and
some very ugly and troublesome code constructs)? The only way I could think
of currently would be using reflection.
I do not think that there is a technical reason they cannot be added, so
much as a semantic one. Its hard to add such a construct in a way that keeps
the language simple. As such, I don't think it would be a clean thing to add
to the CLR, as it would vastly complicate C# and VB, either by adding a new
keyword(I could see something like staticcall b.StaticMethod() or the like,
its ugly though) or by merging static members into the instance member list,
which is also very ugly. I also do not know what kind of a performance issue
it could be.
I really think a contract construct that can specify attributes and
constructors would provide a better solution, especially as the IDE's
mature.
I traced through the responses to the original question, and while I
might have missed something, I feel Chris Capel's question was never
really answered. There were responses about how to do what Chris
wants to do differently, responses that argued the idea, even a nod to
contracts--which I thought missed the whole point.
In the example given, a contract has already been established--in the
form of an abstract class.
I have my own design issue, which brought me to this group in the
first place. I am working on a large number of domain and data mapper
pattern objects. Some of my mappers can handle more than one domain
object, because the domain objects are subclassed.
In order to use a mapper registry (factory) to produce them, I decided
to have each mapper track its mapped types:
public abstract class BaseDataMapper
{
public abstract Type[] MappedTypes{ get ; }
...
}
I think it is reasonable that the author of a mapper should decide
which objects that mapper can map into persistent storage:
public class NamedObjectMapper : BaseDataMapper
{
public override Type[] MappedTypes
{
get{ return new Type[]{ typeof( ServiceType ), typeof(
UnitType ) } ; )
}
}
Now, during registration of the above mapper type in a factory, I need
some way of registering the supported types--from:
mapperRegistry.GetInstanceFor( ServiceType )
I expect the factory to produce the exact mapper I need. Unless the
property described above is also abstract, I cannot do this without
creating an instance of the mapper during registration. Five mappers?
No big deal. Four hundred mappers in a service layer? No way I want
to create an instance of all of those during registration. Not in an
environment where new domain objects and mappers can be added at
runtime, and their types registered.
And this is the thing: attributes? Come on. The issue here is to
force the mapper author to comply with the contract.
So--why not abstract statics?
Because they are messy, if you read everything posted there were a number of
arguments. The most important one is that there is no polymorphic way to
access static methods, you are forced to use reflection and any feature that
REQUIRES reflection to use it is not something that should exist, IMHO.
I would not ever use statics in that manner, attributes exist for just that
purpose(among others, of course). I do however think that a contract that
can handle required attributes should exist, that is a very different matter
entirely.
What is the rationale behind the decision not to allow abstract static
class
members? It doesn't seem like it's a logically contradictory concept, or
that the implementation would be difficult or near-impossible. It seems
like
it would be useful. In fact, there's a place in my code that I could
make
good use of it. So why not?
Chris
