So, if I understand this right (and I may well not), when you instantiate a metaclass you get a class, and when you instantiate a class you get an object, and since anything you instantiate is an object anyway that means classes are objects. I'm not entirely sure if metaclasses are objects, but it seems to lack a certain amount of egregious symmetry if it doesn't.metaclasses are objects as well.
That means, I think, that you ought to be able to call methods on classes, which since you can I think we're mostly OK, though I expect some reworking of base behaviour might be in order. (Though nobody outside of us on the list are likely to ever use it so far as I can tell :)
The one question I have is whether we need to have a "call class method" operation that, when you invoke it, looks up the class of the object and redispatches to it, or whether class methods are just methods called on class objects.
With Ruby class methods are just method calls on the class objects, so there's no for a "call class method" operation.
Languages like Python might need one though but I can't say for certain as my knowledge of Python is very sketchy.
One difficulty is when calling class methods some languages require that you provide the class object as the receiver (Ruby and c# do this) while some languages let you use an instance of the class as the receiver (Java does this)
so in Ruby foo = Foo.new foo.class_method will produce an error
but in Java foo = new Foo foo.class_method will work
Though rather than having a seperate call class method operation it might be better to hide the logic that checks for any class methods withing the JavaObject pmc.
-- Mark Sparshatt
-- Mark Sparshatt
