Re: protected.pm (more Class::Fields)

[Larry Wall <larry@wall.org>]

Gurusamy Sarathy writes:
: I'd agree that we should make attribute inheritance as natural as
: method inheritance, but that's about the only thing that seems like
: an imperative to me in all this.

I'd like to explore how this fits in with lvalue methods.  Attribute
inheritance naturally falls out of method inheritance if we say that
attributes are just methods that aren't implemented via a sub declaration.

And I'm not particularly enamoured of seeing

    $obj->{foo} = $bar;

all over the place.  I suppose there's some small value in documenting
that foo is an attribute rather than a method, but what's the matter
with

    $obj->foo = $bar;

Actually, I'll tell you the matter with it.  It doesn't interpolate:

    print "$obj->foo\n";

We can fix that.  Other than that, I don't see many difficulties.  We
could still use pseudo-hashes for the implementation, provided there's
a way of dealing with MI.  And if we figure out an efficient way to
dispatch attribute methods without a hash lookup, then perhaps we also
gain an efficient way to dispatch ordinary methods without a hash
lookup!

One other thing to figure out if we have attribute methods is how to
break the infinite regress if you want to put a wrapper of the same
name around an attribute:

    sub foo : lvalue, method {
	my $self = shift;
	do_something();
	return $self->foo;	# whoops, calls back to myself
    }

Perhaps $self->{foo} could still mean that, if the actual implemenation
is still a hash or pseudohash.  If not, we might need $self->ATTR::foo
or some such.  I guess the upshot of that would be to disable virtual
foo methods.  Otherwise if a base class said $self->foo, it'd dispatch
to the derived class's foo wrapper.  Hmm, I'm not sure that's a good idea
at all.  If you have a sequence of derived classes that provide nested
definitions of an attribute, you don't want the base classes accidentally
calling into the derived classes merely because they use the $obj->foo
syntax.  You usually want it to mean $obj->MyClass::foo or $obj->SUPER::foo.
Since we have syntactic sugar for SUPER::foo and since $obj->MyClass::foo
is apt to be the most common, perhaps there's a way to "devirtualize"
the foo method by default, based on the fact that it's declared in MyClass.
But then how do you "revirtualize" it if that's what you want?

This tends to drive us back to the notion that we have to refer to
attributes differently within the class than we do outside the class.
The $obj->{foo} syntax currently works okay inside a class.  Perhaps
it can continue to work, depending on how we implement attributes.  And
perhaps it's okay to use a different syntax inside than outside the
class.  Seems a bit weird though.  And it doesn't allow for nested
wrappers.  But presumably we can use the method dispatch for that in
the rare event that we want it.  I dunno.  We obviously need to think
about this some more, hopefully in a less stream-of-consciousness manner.

I'm in a bit of a stupor today, so if anyone less stupid wants to pitch
in, feel free.  If you're equally stupid, but differently, also feel free.
If you're stupider, you're not reading this because you're unconscious.

Larry

---

References to:

Gurusamy Sarathy <gsar@ActiveState.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---