On Sat, Dec 13, 2003 at 01:42:58PM +0000, Andy Wardley wrote:
: How about a single colon?
:
: Color:green
Vaguely possible, but the lexer would have to distinguish
Color:green
Color: green
Color :green
It may yet do that, but probably not for this reason.
: This is the same syntax employed in XML namespaces and URIs, for example:
:
: <xml xmlns:color="http://example.com/xml/color.xsd";>
: <color:green/>
: </xml>
:
: Don't tell me, we can't use : because we're using that for something
: else. :-)
Depends on how we treat whitespace, and whether : becomes part of
the name.
: Presumably, the parser could be smart enough to entuit the
: role on either side of a comparison if the other is specified.
:
: $foo:Color ~~ Color:green
:
: $foo ~~ Color:green # assumes $foo:Color
:
: $foo:Color ~~ green # assumes Color:green
I want more than that. I want
$foo ~~ green
to work, provided there's only one definition of "green" in scope.
That's why I'd like enums to have a mandatory type, so that they
can in fact act like subtypes.
: > I'm thinking the ordinary method
: >
: > $foo.Color
: >
: > implies
: >
: > $foo.as(Color)
:
: What if your $foo object has a regular method called Color? Would it
: get called in preference?
Following the Traits paper's rule, if the class itself defines a
method Color, that takes precedence over any Color methods from roles.
But if the class merely inherits a Color method, the role would
override the inherited method. That being said, I don't think the
situation would arise often in practice if people follow the custom
of naming normal methods in lowercase and classes/roles in uppercase.
Or we could go the other way, and say that, presuming it's known that Color
is a class/role name at compile time, .Color is forced to mean .as(Color)
instantly. It could be argued that this doesn't work so well with run-time
properties. But you can't name a property unless a declaration is in
scope to begin with.
Of course, we could also just completely ignore the fact that Color is
a class name if there's a dot in front of it, and force everyone to
say as(Color) if that's what they mean. That makes the indirect object
syntax a little less useful. Instead of
$bar = Color $foo:
you'd have to say the completely non-English-like
$bar = as $foo: Color
which is perhaps not a great loss if it encourages people to say
$bar = $foo.as(Color)
instead.
Hmm. Now I'm thinking about the problem of expanding references in
list context, since by default a reference doesn't. If you say
print $ref
it doesn't do what you want, but
print $ref.as(Array)
might work a lot better, though of course
print @$ref
does the same thing. But suppose instead of $ref we have a big long
expression returning an array reference. Then the .as() form becomes
much more readable. So it might well be that all the prefix context
operators have .as() counterparts:
~($x) $x.as(Str)
?($x) $x.as(Bit)
+($x) $x.as(Num)
int($x) $x.as(Int)
$($x) $x.as(Scalar)
@($x) $x.as(Array)
%($x) $x.as(Hash)
Though .as() would probably have to be somewhat magical to get the
compiler's context analyzer to realize the context of $x in the way
that the prefix operators do. (And of course it would have to punt
on that analysis if you say $x.as($y) or some such.)
Larry
