On Sat, Oct 15, 2005 at 10:34:34AM -0400, Stevan Little 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.
But you haven't actually said why this is a problem. If you want to know at compile time that a method must be called with an object that has been instantiated, it seems to me that it's pretty easy to tell 99% of the time whether the method body has made reference to $?SELF in some form or other. And if the compiler can determine that, why should the user have to specify it? : 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. Well sure, they're at least opposite ends of a continuum. But we may usefully smudge the distinction in the middle unless you can show actual damage from this. And as you pointed out in your other message, your notion of class is mostly hidden behind .meta in my scheme of things anyway. And generally the compiler will know by inspection whether the body is referring to the dynamic class through .meta, the static class through $?CLASS, or the dynamic instance through $?SELF. (And yes, it bothers me that $?CLASS is static while $?SELF is dynamic. The latter is an abuse of the $? sigil, which ought to be reserved for entities known to the compiler. Maybe we should rename $?SELF to something that looks more dynamic. $*SELF is dynamic, but implies global. Hmm, if $.foo() is really a self call, maybe we could make a case for self being $$. Of course, there's never been any controversy here about what to call "self", oh no... :-) : >But we have to think a bit more about the notion of currying class : >objects into real objects, or something approaching real objects. : : This is an interesting thought, I will have to ponder it some, but it : has a nice smell. Of course I love indian food and functional : programming, so that may be personal bias :) Could turn out that $obj.assuming is just a generalization of &func.assuming. That'd be kinda cool. Larry
