On Dec 2, 2005, at 0:42, Allison Randal wrote:
I realize this is a side effect of the fact that method names are
actually strings, but it's an unfortunate result.
.sub main :main
newclass $P1, 'Thingy'
$P2 = new 'Thingy'
$P2.snark()
end
.end
.namespace [ "Thingy" ]
.sub snark method
print "Boojum\n"
.end
But, if I were to foolishly have a local PMC variable of the same name
as the method in the same compilation unit as the method call, then it
tries to invoke the local variable:
Yep. Which might sometimes be, what you want to do:
.sub main
.local pmc snark, o
$P0 = newclass 'Thingy'
snark = find_global 'Thingy', 'snark'
o = new .String
o = o.snark()
print o
.end
.namespace ['Thingy']
.sub snark :method
.return("ok\n")
.end
There's an easy way to ensure the clash between method names and local
variables never happens: always wrap the method name in quotes. This
will never try to invoke the local snark variable, because it knows
the method name is a literal string.
Yup.
So, my question is, should we prevent the obj.method() syntax from
ever being interpreted as object."method"()? It's nice convenient
syntax, but makes for some pretty nasty collisions. Or, maybe there's
another solution, like requiring some explicit way of marking when
obj.method() is doing anything other than obj."method"(). (That at
least has the advantage of making the common case the default.)
Maybe obj.$method(), where the token '.$' means the method is a
variable?
Allison
leo
