HaloO,
Larry Wall wrote:
On Wed, Oct 26, 2005 at 04:59:04PM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-26 7:31 (-0700):
: > One slightly serious ramification of the : switch is that the space
: > is required after the colon indicating a null invocant.
What is an invocantless method other than a sub?
: > method doit (: $a, $b, $c)
:
: Or, we could separate it with a . instead of a :, perhaps?
I have proposed to markup invocant parameters with a leading dot
sigil. More than one invocant either makes it a multi method or
a mono method on a more complicated type. If the zoning of parameters
is dropped however, interpersed dotted params might make Perl approach
Cecil in that respect and surpass it with combining dispatched params
with named params.
:
: This is already more or less very heavily associated with invocants
: anyway.
Yes, and dispatch as a runtime keyed access into a code multitude.
The covariant part of the method's sig! The code equivalent to keyed
data access into hashes.
I think a . would be too lightweight visually within the signature.
Plus . is a postfix prefix syntactically, not a delimiter.
How are multiple --> handled in a method sig? The standard case
of a method defined in a class puts the class type into a primary
or pre-dispatch position, or not? I mean that
class Foo
{
method bar ($x, $y) {...}
}
might just mean
class Foo
{
method bar (¢Foo $?SELF --> $x, $y --> ) {...}
}
The left --> is just the virtualizer call. I tend to call
that slot accessor. The return value of a dispatch is the
not yet invoked but curried on the invocant(s) method. This
two stage propcess is in my eyes nicely indicated by the
two -->. But we could also but a : in the dispatch arrows
like -:-> or :-> or -:> which all look somewhat ugly.
: Hmmm...
:
: method .doit (...) { ... }
: method $foo.doit () { ... }
I think it would be a mistake to move the invocant outside the
signature. We've just taken pains to move the return type *into*
the signature.
But the distinction between the dispatch/covariant part and the
contravariant lhs of the arrow type is difficult if we allow multiple
arrows in sigs. I would therefore like to propose anpther trait for
methods: the 'on' part. To wit:
method doit (...) on (invocant sig) { ... }
Well, we could take the ¢ sigil to form invocant twigils ¢$, ¢@, ¢%, ¢&
which look a bit nicer with ^ though: ^$, ^@, ^%, ^&. The association
with $^, @^, %^, &^ in placeholders is a bonus in my eyes because they
are post dispatch on void invocants :)
The guiding theme in my line of thinking about twigils is that there's
a void between their two chars. A "pair" of type constraint and uncaptured
actual invocant type so to say. Well and we could capture it with
method doit ( Constraint ^Actual $foo, NonInvocant $blahh ) {...}
to deal have it available inside. Am I makeing sense? Which impact all
this has an the self method discussion I don't know, but ^. and .^ come
to mind. The former would make ^.foo a method on the current invocant
and a bare .^ would dispatch the current method on the topic or some such.
--
$TSa.greeting := "HaloO"; # mind the echo!
