On Oct 17, 2005, at 7:35 AM, Miroslav Silovic wrote:
I think what bothers me most about this is that it seems there is no way to tell the difference between class methods and instance methods. That the distinction is only made when the body of the method does something which is is not supposed to do (method called with a class invocant attempts to access an instance variable, etc).

This is one of the major problems that I have always had with Perl 5 OO. That there is a very fuzzy fuzzy line between the responsibilities of a class and an instance.

I can see the notion of "a class which is not yet instantiated", this makes sense in many contexts. But I don't think that in order to have this, we need to bring back this element of Perl 5 OO. I think we can still have all the behaviors you have been describing, and still keep classes and their instances as distinct entities.

It just recently occured to me that Class is a Package.

Actually, to be precise, Class is a Module, and Module is a Package. Modules add the version and authority portions to the name of a Package, and it seems that exporting (as traits?) are Module things, and not Package things.

So, on the object model level, class methods/attributes belong to the Package part of a class, while instance methods/attributes belong to the Class part of a class - insofar as they're made distinct by use of my/our.

Well, currently in the prototype, class attributes defined with "our" are stored in the Classes symbol table (which is inherited from Package). Discussions with autrijus lead me to not address class attributes defined by "my", since he felt they would be better addressed as "normal" variables within the scope of the class body. This is somewhat of an implementation detail, however, I think it may also play a part in how these things work. For instance, in the following example, is "$.foo" a class attribute? or just a local variable for the inner block?

class Bar {
    our $.bar;
        my $.foo;

I assume that the leading "$." is what makes the difference, however, IIRC the "$." is just part of the name, and no more special than that. Which means that I can choose that name (yes, it is evil, but I assume I can still do it).

But given that the variable will be accessible to all methods via the closure mechanism, the only thing missing I think is the ability to get at the variable via introspection.

Now, as for class methods, I suppose it is possible to just stash then in the classes symbol table like with variables. However, do we then loose the method call syntax? This also means that they would not (directly) be inheritable since inheritence moves along superclass lines, and not with @ISA. I am also not sure what you mean about multi-methods either, could you please explain more?



Reply via email to