HaloO Sam,
you wrote:
This in turn implies that the $.foo syntax is, in general, bad
practice!
Yup.
I claim the opposit. But I might have a very different meaning in mind
when I say that. So it's opposit in an orthogonal direction :)
Not very huffmanised, is it?
The syntax is just right for the statefull, imperative programming style.
If that is not your thing, so be it.
Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute
$.SUPER::foo
Hmm? Isn't a $ sigil expression a single scalar typed, referential
expression anymore? The secondary . sigil is in my eyes just perfect
to express self reference! If I use %.arm<left> to scratch %.leg<right>
it is pretty much clear which particular parts of my body are involved.
And if I give a rw reference to $.guts to a surgeon method it is just one
possible result that some parts have become undefined or look funny ;)
And yes, this means a *dynamic* change of self type! E.g. a changing
$.belly_circumference could change a man from .does(LeightWeight) to
.does(HeavyWeight).
What I do *not* understand is what or where $.SUPER::brain should
refer to. If Perl6 avoids the problem of 'schizophrenic self reference'
where some methods make false assumptions about the object layout
or have access to hidden parts then all methods which shall be applicable
to the object's referential environment must be type sound. This means for
example that the type system prevents dispatches to base class methods
even though the invocant is instanciated from a derived class. This is a
typical example where Rotweiler instances are *not* a subtype of Dog
instances---at least not as far as playing is concerned.
The example with the $.collar in the Rotweiler class could be
solved by forcing the slot into outside constness which has
the side-effects that the Pet::loose_collar method is not applicable
and thus the $?SELF.lose_collar() call in Dog::play has to dispatch
elsewhere or fail! In other words: Rotweiler.does(Dog::play) is false!
A strong type system can find that out, a weaker one let's the code
die in Pet::loose_collar on const assignment.
Then we could even sneak in making $.foo(bar) a not-so-offensive
./foo(bar),
with ($.foo)(bar) meaning what $.foo(bar) currently means. But that really
is a seperate issue, and speculation of it meaningless if we retain the
current specified behaviour.
I'm seeking a solution along the ideas of homogenious self reference
as outlined above. This would e.g. allow the &.foo code ref to mean
a ref to the most specific method applicable to the self type unless
the programmer has arranged that something else is stored there.
As long as the method requires arguments there is just the one char
inconvenience of typing &.foo(1,2) instead of .foo(1,2) or whatever
syntax implicitly derefs and calls &.foo with $?SELF as the invocant.
Then there is also room for some dwimmery for dispatching .foo through
$?SELF when the type of $_ would fail the dispatch. So from a certain
point of view I like $Larry's ruling that the compiler has to statically
insure that the self type puts the invocant into a fair position for the
dispatch at hand. Perl6 is (type)strong in the source ;)
Another thing I do not understand from a typing point of view is how
perlkind expects a simple .foo expression in the lexical scope of a
class which defines a method foo to be usefull on a random $_ with a
type that is incompatible with the $?SELF type of the invocant of the
method that this .foo call happens to be written. An example:
class FooDefiner
{
has $.text = 'FooDefiner hit';
method foo { say $.text }
method foocaller
{
for 1..3 { .foo } # 1
for 1..3 { foo } # 2
}
}
I think compile time name lookup in both lines resolves to
&FooDefiner::foo which requires a self type of ::FooDefiner
and I think that Int.does(FooDefiner::foo) is false. So an
invocation of &FooDefiner::foocaller would simply produce
a type error or six warnings and no printout if the foo calls
are dispatched over $_, right?
Regards,
--
TSa (Thomas Sandlaß)
