Klaas-Jan Stol (via RT) wrote:
Hi,
This proposal is about resolving method names: bare words or quoted
it might be that i'm not well informed on this issue, so please correct me
where I go wrong.
IMCC currently allows for method call syntax like this:
foo.bar()
foo."bar"()
Both invoke the method named "bar" on the object "foo", UNLESS there is a
local variable named "bar", in which case the first statement will invoke
the method whose name is stored in that local variable.
This is confusing, and makes reading code not easy (imagine having a
subroutine of 50+ instructions, and debugging it)
Agreed on the problem. I've raised it myself several times over the
years, especially right after nasty debugging sessions where I was
caught by it.
PCCMETHODs (a method on a pmc written in C) is, IIRC, invoked using a bare
word methodname like so:
foo.bar()
So, what is called here? Is bar a method, a PCCMETHOD (but I guess that does
not matter), or a local variable containing the name of a method?
For methods, both foo.bar() and foo."bar" translate to:
callmethodcc P1, "bar"
For subs, both bar() and "bar"() translate to:
set_p_pc P0, bar
...
invokecc P0
For methods, a call to foo.methname(), where methname is a .local
string, translates to:
callmethodcc P1, S0
and calls the method just fine. While a call to subname(), where subname
is a .local string, won't even output PASM code, and gives an error:
error:imcc:Sub isn't a PMC
For both sub and method calls, if bar is a .local PMC String, you get
the error:
invoke() not implemented in class 'String'
Which is not useful behavior at all.
In order to prevent confusing, I propose that methodnames are always written
between quotes. This should also be true for PCCMETHODs.
Only then is it always clear when calling a method whose name is stored in a
local variable, or if it's actually the name of the method that was written.
I've always been annoyed by the quotes around method calls. Too much
typing, too distracting when reading/modifying code (making it difficult
to pick out the real constant strings). It's true that it's just a
matter of syntactic sugar, but then the only value of the abbreviated
method call syntax is syntactic sugar to make the programmer's life
easier. It doesn't help the compiler either way.
I think the method "new" on a class is a PCCMETHOD, right?
Yes.
This would mean that you would create a new object instance like so:
local pmc b
b = Foo.new()
Having to write
b = Foo.'new'() might seem inconvenient, but I think it's a matter of
getting used to, and it is more consistent.
Consistency is good.
Agreed that consistency is good. In this case the most important
consistency is between method and sub calls.
The assembly language (if you can call PIR that) should not have too many
rules and exceptions.
I think the most surprising inconsistency is the fact that you can use a
string literal or string register as a sub/method name, but not a string
PMC. That's not normal behavior for Parrot. In most places any of the 3
will do. And, there's not really a good reason for it here, it's just
literal-minded syntax that expects all PMC arguments to be invokable.
It's also a need for fast method calls, which makes checking the type of
the PMC argument undesirable.
We haven't yet come up with an alternative that's clearly better than
what we have now. Add a note on this proposal to the PIR PDD and I'll
review it and any other proposals on the problem all at once.
Allison
