C# specification omission? Lack of static interface properties

  • Thread starter Thread starter ~~~ .NET Ed ~~~
  • Start date Start date
N

~~~ .NET Ed ~~~

Yes, I think so at least... In C# you *can* have static properties which are
quite useful when used properly. Now imagine the scenario where you need the
ability (sp?) to implement a variety of classes that must implement an
interface. All these classes must have a particular *static* property, and
this in particular is handy not only to be consequent with the fact that you
can do it with classes but also with the fact that you cannot specify member
variables in an interface (which IMHO is good that way, ie no member
variables in an interface definition).

And then... you happily put your static interface property that all the
implementing classes must implement and then "Invalid attribute for an
interface member" !!!

I believe this is an omission in the specification, sadly now I must find
another less straightforward way to achieve the same.
 
~~~ .NET Ed ~~~ said:
Yes, I think so at least... In C# you *can* have static properties which
are
quite useful when used properly. Now imagine the scenario where you need
the
ability (sp?) to implement a variety of classes that must implement an
interface. All these classes must have a particular *static* property, and
this in particular is handy not only to be consequent with the fact that
you
can do it with classes but also with the fact that you cannot specify
member
variables in an interface (which IMHO is good that way, ie no member
variables in an interface definition).

And then... you happily put your static interface property that all the
implementing classes must implement and then "Invalid attribute for an
interface member" !!!

I believe this is an omission in the specification, sadly now I must find
another less straightforward way to achieve the same.
Click to expand...

Actually, this would be the less straight forward way of achieving what you
want(which may or may not be an appropriate pattern to begin with).

Here is the big problem, "How do you call a static interface method?"
It cannot be called on the interface type itself, because the interface has
no ties to a particular type and therefore cannot be used to call a...how
would you put it, virtual static method.

It cannot be called on an interface instance since the instance has no
specific type associated with it at compilation time, thus the compiler has
no way of determining what static method to call(this is, of course,
ignoring the fact that C# doesn't allow static member access through
instances).

Equally, you can call it on the class, but then there is no point in
providing it in an interface as the interface itself cannot be tied to it
and you have to know the exact type to use it, breaking many of the benifits
of interfaces.

This particular functionality should not exist in interfaces. It is actually
probably the domain of a construct a step or two above interfaces, but I do
not know of a langauge that really supports the level of contractual
specification you desire.
 
Why not create a property in the interface that is non static. Then in the
class definition itself have that property get/set the static member of that
class type. Seems pretty clean to me. You can use some kind of naming
convention to let others know what the plans for this property are if you
are going to be sharing this code with co-workers.

Interfaces don't have types so if you had a an interface that several
classes derived from and tried to call a static method or property of that
interface, how would it know which classes static method to execute? (This
was explained very nicely by Daniel)

jim
 
Good points indeed and yet it is something I have missed on several
ocassions. What I had indeed
was an instance property that accessed a static member, only to use that I
must first create an
instance of the class (and in this case just for that purpose) and that
seemed a bit of an overkill.

Then I considered simply using a static public member, but then the whole
purpose of using an
interface for this particular situation is missed.

Another alternative was to use an abstract class instead of an interface and
use the "is" operator but
again that seemed like an overkill, not to mention that if you need that
class to also inherit for another
then you reached the end of the rope.

Anyway thanks, I will have to resort to some of these workarounds.
 
James Curran said:
Well, I guess the one practical use of such a beast, is that it will
allow the compiler to bitch at you, if you forget to implement it.
Click to expand...

Yes, and constructors could be handled in the same way.

I always feel there's practical room for such static methods and
constructors, but there really are theoretical reasons against them.
I'm not sure the theoretical reasons should overpower the practical
reasons, myself, but there we go. We'd need to invent some new syntax,
of course. Something like:

Type t = <dynamically load a type here>;

ISomeInterface(t).StaticMethod(...);
or
ISomeInterface instance = ISomeInterface(t).new(...);

I'm sure someone can come up with much better ideas. They really would
help for plug-in development.
 
Jon Skeet said:
Yes, and constructors could be handled in the same way.

I always feel there's practical room for such static methods and
constructors, but there really are theoretical reasons against them.
I'm not sure the theoretical reasons should overpower the practical
reasons, myself, but there we go. We'd need to invent some new syntax,
of course. Something like:

Type t = <dynamically load a type here>;

ISomeInterface(t).StaticMethod(...);
or
ISomeInterface instance = ISomeInterface(t).new(...);

I'm sure someone can come up with much better ideas. They really would
help for plug-in development.
Click to expand...

These mechanisms cetainly would be rather valuable, however I don't think
they are nessecerily appropriatly applied to interfaces. Interfaces have an
established meaning already and should not be significantly extended, IMHO.

I think the nessercy contracts really extend beyond methods and
constructors. A real contracting system like this would ideally allow
everything from static methods and constructors to required interfaces,
attributes, generic type specifications, and potentially Design By Contract
style assertions or constraints that define the contractual domains
input(that is, allow a *contract* to specify that MethodA(int) will only
recieve values between 1 and 4822 while the method itself may assume any set
that contains 1 - 4822), or even maybe a language\runtime supported factory
system. Atleast, that is my opinion.

The problem really is tying it all together without complicating the
language significantly. As I hinted to in my original response, static
method may well sit two levels above interfaces, where the first level may
be DbC and input\output constraints.
 
Back
Top