Larry,
On Oct 15, 2005, at 11:25 AM, Larry Wall wrote:
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 think it is a problem because they are two distinct areas of
responsibility. A class creates and manages instances, while an
object is the thing which the class creates. The object only manages
it's own data.
As for whether the compiler can tell the difference, I am not sure
you are correct here. Take this for instance:
class Foo {
method bar {
$?CLASS.baz();
}
}
What is &bar? A class method? or a instance method? Clearly $?CLASS
is valid inside instance methods, and surely you can call methods on
$?CLASS within instance methods. There is an ambiguity here.
One possible solution of course is that this method is both, that it
could basically be this (to use the old A12 syntax):
class Foo {
method bar (Class|Foo $f:) {
$?CLASS.baz();
}
}
I am fine with that personally.
My biggest concern is that we are able to fit the syntax into *a*
meta-model. As I said before, I don't have a problem scrapping the
current version and starting on v3.0, I enjoy writing and thinking
about these things, so you will get no resistance from me. However, I
want to be sure that I know what it needs to do, then I can determine
if I even need to re-write it or not.
: 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.
I don't think there is actually damage, we just have methods which
can be called in either context. How to implement this is fairly
easy, so I am not worried about that. I am just not comfortable with
*all* methods being in this grey area.
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.
Yes, except in the case I show above, but then we can just use the
solution I show above.
(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... :-)
I don't even want to get into this debate, I am just the meta-monkey,
nothing more :)
Thanks,
Stevan
