On Thu, Mar 12, 2009 at 03:05:17PM -0300, Daniel Ruoso wrote:
: Em Qui, 2009-03-12 às 10:28 -0700, Larry Wall escreveu:
: > On Thu, Mar 12, 2009 at 08:51:45AM -0700, Ovid wrote:
: > : > From: David Green <david.gr...@telus.net>
: > : > I suppose, but is there a reason why you want to apply roles instead of
coercing
: > : > the results?
: > : Because I am coming from Moose instead of Perl 6 and didn't know about
this :)
: > Note however that coercions require parens these days, since types parse
: > as values, not as routine names.
: > $x = Role::Serializable::XML($resultset);
: > $y = Role::Serializable::YAML($resultset);
:
: Er... wouldn't that create a proto-object sending $resultset as the
: attribute for the only attribute that the Role can have? being the
: equivalent to:
:
: $x = Role::Serializable::XML{ :attr($resultset) }
:
: It is even supposed to fail if that Role declares more than one
: attribute...
:
: Or am I missing something?
In addition to what Jonathan said, it is possible that the ability
to coerce multiple arguments depends on the type itself, since we
probably want to allow Foo(1,2,3) and such for listy types that
don't necessarily want to use the [1,2,3] shortcut.
But my main point is that $x = Foo $bar is a two-terms-in-a-row
error when Foo is anything resembling a type, enum, or value, none
of which expect to be turned into a listop or prefix. This is
independent of how the object might respond to (), if at all.
Oh, btw, re irc conversation the other day, .() and () are always
identical in postfix position, just as .++ and ++ are the same.
The . carries no semantics when qualifying a postfix, even when
accessing attributes $.foo.() vs $.foo(), which mean exactly the
same thing because such postfixes are part of the special form.
Or to put it the other way, anything that parses postfix:<( )>
ought to parse postfix:<.( )> identically, as well as all
the unspace variants.
It's possible this role of . could be taken over by \ instead, I
suppose, since $.foo\() is also unambiguously a postfix. (We added
the bare \op form to distinguish the $x.i method call from the
$x\i complex number.) But we've gotten accustomed to use .() for
clarity in conversation, and \() won't achieve that, given its use
for Capture terms. So it seems we're stuck with both.
And now I'm completely off topic, unless the topic is Perl 6. :)
Larry
