HaloO,
Juerd wrote:
This aside, you could of course just double the colon. Or use a
semicolon.
Semicolon would give me the mnemonic of 'end of statement' seperating
the dispatched part from the checked part of the signature. Or it
reminds one of the array and hash slicing. Should we call dispatch
call or code slicing?
:( Int, Int ; Str, Num --> Foo )
A slot call would then retrieve the method from the object first
:( Item ^X --> ^X ; Foo, Bar --> Ret )
Assuming we use ^ instead of ยข as the captured type sigil. Which
leaves the question how arrow type invocant methods relate to
non-arrow type invocant methods? Hmm, non-arrow types can always
be regarded as :( void --> ^X ) and the usual contra-variant subtyping
rule would make :( ^X --> ^X ) more specific if void were more specific
than ^X. But I think the opposite is true! That is any value can go
to void context and be ignored. In other words void is a type close to
the universal type. By the same argument any method is more specific
than subs which have void as invocant type.
I like the outcome that a free method on the same type has higher
dispatch precedence than the corresponding slot call. YMMV, though.
OTOH, the free method might not have the privileged access that a
'inside class definition' method has. But then such a outside overrider
might just delegate to the insider routine through explicit slot access.
But how does that look like? I think
method bar (Foo $x) # all params dispatched, hence ^ optional
{
say "outside Foo :)";
$x.Foo::bar(); # slot call
}
should do the trick. But then again, there might be no free methods
in Perl6.
I just really wouldn't like : to have two very different meanings in very
similar places.
I'm split on the issue because of the similarity to the label syntax. The
indirect object syntax is then the call continuation after the dispatch
target selection and invocants binding or some such.
--
$TSa.greeting := "HaloO"; # mind the echo!
