Re: Re(vised): Proposal to make class method non-inheritable
[EMAIL PROTECTED] 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. 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. Larry's proposal is to remove that difference for multimethods. Personally I can't think of a good objection to that idea (except if it may be bad for performance - is there a plan to infer types and auto-inline? I that case, declaring that you don't care about instance part of the object's functionality can really help). Miro
Re: Re(vised): Proposal to make class method non-inheritable
Miroslav
On Oct 17, 2005, at 7:35 AM, Miroslav Silovic wrote:
[EMAIL PROTECTED] 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?
Thanks,
Stevan
Re: 'self' and .foo (was: Re: Re(vised): Proposal to make class method non-inheritable)
On 2005-10-15 15:28, Ilmari Vacklin [EMAIL PROTECTED] wrote: On Sat, Oct 15, 2005 at 09:49:30AM -0700, Larry Wall wrote: On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote: : IMHO just call it self (by default) and be done with it. :) Let it be so. Somewhat off-tangent: does this mean that .foo is always $_.foo? tic glazed, far-off look in the eye INCOMING!! opens desk drawer, rummages around for hand grenade . . . Hunh. Who'da thunk - apparently even *flame* wars can trigger post-traumatic stress disorder...
Re: Re(vised): Proposal to make class method non-inheritable
HaloO,
Stevan Little wrote:
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?
I think not. But the current notion seems to drift closer to my
idea of free methods versus slot calls. To express that in therms
of your initial equation
object == state + behavior
would be expressed on the first meta level as
class == data(structure) + code(structure)
which means that the compiler syntactically splits the class
definition into an active and a passive part. Call this symmetry
breaking if you like. The same asymmetry exist in the method call
syntax
$foo .action;
because the compiler compiles that into a lookup of 'action' from
the method part of the MIR (Meta Information Repository, World in Russian)
followed by a dispatch on the actual runtime type referred to by $foo.
In other words, the name that connects the compile and runtime is 'action'.
If this name shall be retrieved from the instance at runtime without going
through the method dispatcher I have proposed to wrap-up the name as
$foo :action;
Without the $ sigil a bare foo is interpreted as a name lookup in the code
part of the MIR which is the union of all subs and methods---subs beeing
nullary methods so to speak. That gives
foo .action; # dispatch action on retval of foo
and
foo :action; # bind named param in the call to foo.
These two things are on the tightest precedence level, which in my eyes
makes . and : meta sigils or some such.
We could actually combine these with the idea of the current name beeing
a sigilled underscore and '_._' denoting the current method on the current
topic, and '_:_' the current key from the current topic :)
Hmm, these would make {_} the closure of the current continuation or so.
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?
Symmetric MMD at least has the meaning that the above mentioned asymmetry
doesn't exist for infix ops on the syntactic level:
$x foo $y;
which neither means
($x foo) $y; # calculated prefix op from postfix foo
nor
$x (foo $y); # calculated postfix op from prefix foo.
I can't speak for metric MMD, though. But IIRC, the metric is
'sum of superclass hops'.
--
