Calling static methods on type parameters is illegal, part three

re: Calling static methods on type variables is illegal, part three

Tim Watson — Wed, 26 Sep 2007 03:12:14 GMT

An improved reflection api? Let's face it, nobody has really done this more clearly than in smalltalk, so perhaps the following (deliciously Ruby-ish) would suffice:

var subject = GetSomeObjectOrOther();

var args = { "firstArgument", "secondArgument" };

operationName = "Foo";

var result = subject.Send( operationName, args );

Although the notion of 'sending messages' is probably a bit alien to some community members; perhaps this would work better instead?

subject.Dispatch( operationName, args );

The second parameter can be a param-array of type System.Object. I wonder about methods with void return types though: can there be one signature that fits all? Or will we start seeing stuff that looks reminiscent of VB (gasp!) such as

subject.Dispatch( "CreateAccount", accountNumber ); //void return type

var balance = subject.Call( "GetAccountBalance", accountNumber );

As for property access, what about something pythonic, such as:

var name = obj.GetAttribute( "Name" );

obj.SetAttribute( "Name", "new_" + name );

Either way, having new methods on System.Object seems better than messing around with the syntax, or am I missing something here!? Also, this would work with *static* methods (because System.Type extends System.Object and is [effectively] the metaclass of a class).

But this kind of thing can go too far...

class MyType : System.Type { ... } // s c a r y ! ! ,,, -_- ,,,

re: Calling static methods on type variables is illegal, part three

David White — Mon, 17 Sep 2007 08:34:00 GMT

Here's a potential use case for access to the AST (abstract syntax tree). We'd like to be able completely parse the source code, including pre-processing directives, to be able to intelligently merge source code changes with regenerated code, even if the user re-orders or renames classes, methods, etc. Current parsers (or at least the ones we've tested to date) struggle with pre-processing directives.

re: Calling static methods on type variables is illegal, part three

JohnMcD — Wed, 12 Sep 2007 07:03:40 GMT

I came across this blog when I was trying to find out why C# didn’t allow virtual static methods or virtual constructors. I’m used to using virtual constructors, virtual class methods and class references in Delphi and I’ve been really frustrated by their absence in C#.

This blog has clarified the difference between static methods and class methods.

You said earlier in your blog “[people ask me] why C# does not support “virtual static” methods. I am always at a loss to understand what they could possibly mean, since “virtual” and “static” are opposites! “virtual” means “determine the method to be called based on run time type information”, and “static” means “determine the method to be called solely based on compile time static analysis”.

I would like to argue the benefits of virtual class methods:

When a base class has a virtual constructor and various virtual class methods, each subclass can implement its own versions of the constructor and class methods.

It’s largely class references that make virtual class methods and virtual constructors so useful, but they would also be very useful with generics. (Generics are not implemented in the current version of Delphi).

Class references in Delphi are a little bit like the Type class in C#, but they can be restricted to just the types that derive from a particular base class, and you can call any class methods or constructors that have been defined in that base class from the class reference. When the class methods are virtual you get the version appropriate for the class reference.

(When you’re used to this functionality, you wonder why anyone would need to use factory patterns. I like the comment about most design patterns being necessary when the language has failed to provide a needed feature natively).

For example, virtual class methods could be used to return a description of the class, to determine whether the class could do some required action, or ....

These classes can all be registered with some manager object, which can then use the class methods to determine which class is appropriate for some action, then create an instance of that class.

In a C# like syntax (and using static with a slightly changed meaning), it would look like:

public abstract class Animal

{

public abstract static Animal Create();

public abstract static bool CanFly();

public abstract static string Description();

public abstract static int LegCount();

}

public class Eagle: Animal

{

public override static Animal Create()

{

return new Eagle();

}

public override static bool CanFly()

{

return true;

}

public override static string Description();

{

return “Large raptor”;

}

public override static int LegCount();

{

return 2;

}

unknown syntax declaring AnimalClass = class of Animal;

private List<AnimalClass> animalClassList;

animalClassList.Add(Eagle);

foreach (AnimalClass animalClass in animalClassList)

{

if ( animalClass.CanFly() )

aviary.Add(animalClass.Create());

}

This sort of thing is very simple to do in Delphi, and requires much more convoluted code in C#.

re: Calling static methods on type variables is illegal, part three

Eric Lippert — Sat, 23 Jun 2007 01:19:40 GMT

Stuart: That's certainly a possibility, though I find obj."Method"() weird. If you know the name already then why are you doing it dynamically?

In your examples, either its a string literal or a parenthesized expression. The string literal scenario is I think sufficiently implausible that we can not optimize for it -- just put the string literal into the parens if you really want to do that for some strange reason. Then we have only parenthesized expressions to worry about.

This would then have the nice property that you could do

obj.(blah)(whatever)

for any expression blah of type string.

Having parentheses, or some other token to call out dynamism, is probably necessary if we want the semantics to be both unambiguous and not brittle. We do not want to get into this unfortunate situation:

string Method2 = "Method1";

obj.Method2(); // If I then add Method2 to my object, does this call Method1 or Method2? brittle!

obj.(Method2)(); // unambiguously calls Method1.

This also has the nice property of not being legal syntax now, since the thing that follows the dot must be an identifier.

re: Calling static methods on type variables is illegal, part three

Phil Parker — Fri, 22 Jun 2007 10:56:56 GMT

Here's another one which I've been mulling over ... nowhere near a use case, or for that matter even really a complete thought, but I've been wondering about the possibility of enforcing immutability contracts over types.

My personal preference is to keep mutability to an absolute minimum, for the obvious simplifications it brings to concurrency and avoidance of client mutation of shared state exposed by APIs.

However, in some cases, there are patterns, usually dealing with extensibility where I would like to be able to enforce immutability. Either as a constraint for internal developers or possibly third party developers.

Not sure if this would really play with what you're indicating as far as exposing compiler internals. So far, I'd been thinking of it as more likely to be a reflection and decompilation activity at runtime, which would be far too hairy for me to attempt (I have a real job!) and of course would at best only deal with managed code.

Sorry this isn't really a use case. Just some musings.

re: Calling static methods on type variables is illegal, part three

Max Bolingbroke — Fri, 22 Jun 2007 05:19:58 GMT

Access to C# compiler internals would really help me accomplish what I'm trying to do. Basically, I have a working compile time metaprogramming system for C#, which postprocesses an assembly to e.g. add code to check for nulls for method parameters marked with a [Required] attribute. This is limited however, because it can only implement transforms that do not change the interface of the class in any meaningful way: this means that I cannot, for example, create a [Property] macro which could be attached to a class field and spits out the getter/setter at compile-time for you.

However, I'm not sure if you guys are great fans of metaprogramming: it would certainly be a bit "out there" compared to the features C# has at the moment. And people can always use Boo, especially with the new meta methods feature (http://blogs.codehaus.org/people/bamboo/archives/001593_boo_meta_methods.html).

re: Calling static methods on type variables is illegal, part three

Stuart Ballard — Fri, 22 Jun 2007 03:01:42 GMT

My thought on dynamic method/property access:

obj."Method"();

obj.("Meth" + "od")();

obj."Property" = value;

object value = obj.("Prop" + "erty");

The return value from a dynamically invoked method or property getter would always be of type object.

On the topic of class-level virtual methods, if you accept that in the C# world "static" no longer means "defined at compile time" but rather "associated with a class rather than an instance", how about saying that a method can be defined "static virtual" to have the behavior people want?

re: Calling static methods on type variables is illegal, part three

Barry.Kelly — Fri, 22 Jun 2007 01:29:50 GMT

I work on the Delphi compiler at CodeGear.

Delphi class methods are instance methods on a metaclass. All classes have one and only one metaclass instance, and a class type identifier is a literal for accessing that value in an expression.

Constructors are effectively class methods, but with special magic to handle things like allocating an instance. This means that constructors can be virtual; this can be taken advantage of with variables of a metaclass type. Variables of a metaclass type are a lot like a runtime kind of type parameter, and can similarly be restricted to descend from a given ancestor. For example:

---8<---

type

T = class end;

U = class(T) end;

Tc = class of T;

Uc = class of U;

var

x: Tc;

y: Uc;

begin

x := T; // ok

x := U; // ok

y := T; // not ok

y := U; // ok

x := y; // ok

x.M; // if T has method M, it can be called like this

end.

--->8---

Class methods are basically implemented on .NET as instance methods of a singleton static final field associated with the type, looking roughly like '@MetaFoo' for a class 'Foo'.