On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
> On Thursday 28 September 2006 11:25, Allison Randal wrote:
> > obj.{bar}() # a string method name
> > obj.{$S1}()
I'm not sure what's meant by "a string method name" above, but
I'd look at it as:
.local string abc
obj.'abc'() # call 'abc' method of obj
obj.abc() # always the same as above
obj.{abc}() # call method indicated by abc symbol
obj.{S0}() # call method indicated by S0
obj.$S0() # call method indicated by $S0
Having obj.abc() always mean obj.'abc'() seems to me like it's
most in line with what PIR-authors expect.
As noted in the last instance, I don't know that we need a
separate obj.{$S0}() case since the dollar sign is sufficient
to distinguish exactly what was meant. But there's also an
argument in favor of the consistency of {...} always meaning
"evaluate this" as opposed to "treat this as literal" given
by the bareword and 'abc' forms.
> To push a little more the other direction, is it possible for the
> compiler to detect symbol and method name conflicts?
> It's only the collision that makes a case ambiguous, right?
I don't think that the compiler always knows at compile time
what method names are available for any given object, so detecting
"collisions" could be problematic.
However, it could certainly detect when a bareword symbol has
been used as a method name and warn about it, requiring the use of an
explicit obj.{symbol}() or obj.'symbol'() form to disambiguate it.
Pm
