Klaas-Jan Stol wrote:
hi,
IIRC (currently no pc around to check, but I realized this issue when
reading on objects pdd), calling a method in PIR can be done as follows:
$P0.'someMethod'()
but also:
.local string meth /* or maybe a pmc ?*/
meth = 'someMethod'
$P0.meth()
This is a long-standing IMCC issue and also affects subs. The PMC
variant also works:
.local pmc meth
meth = # fetch the method object
$P0.meth()
However, this looks like as if the object in $P0 has a method called
'meth',
just as a class object has methods like 'inspect', and 'roles'. This is
imho
a bit unfortunate, it makes this syntax a bit ambiguous.
It gets tricky if you have some variable that goes by the same name, like
'inspect', or 'roles'.
An annoyance I've been caught by before.
So, I would suggest to disallow arbitrary objects holding methods for this
syntax; only allow for strings as method names, or barenames if they are
known to be methods on the PMC.
That doesn't quite get around the problem, because you still have the
ambiguity, "sometimes it's one thing and sometimes it's another". And if
barenames are allowed for the methods that are defined, what if you
write some code passing in a named variable containing a string method
name, and then update the object to have a method of that same name?
We could entirely disallow barenames, so it's always either a quoted
string or a variable.
But even that doesn't solve the problem, because currently if the method
name is a string PMC:
$P0 = new String
$P0 = "hello"
object.$P0()
It tries to treat the PMC as a method object and gives you the error
"invoke() not implemented in class 'String'".
We need more distinctions in the PIR syntactic sugar. On the drive home
from the last Portland Perl Mongers meeting I was kicking around
something a little Perl 6-ish.
object.method() # bareword methodname
object~method() # string variable name (string or PMC)
object!method() # invoke PMC method object
But those differences are really hard to see. So, this lingers on as an
unresolved question.
Allison
