On Tue, May 08, 2007 at 12:38:43PM -0700, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >
> >Well, since I've only come across a single case where the
> >method I needed to call was in a String PMC, I've never found
> >it annoying. But again, perhaps that's just me and it really is
> >a big annoyance to other PIR programmers. :-)
>
> Oh, I was talking about a complete solution to the ambiguity: no string
> method calls at all, only method PMC objects. So, eliminate these too:
>
> object.methodname()
> object.'methodname'()
> object.$S1()
>
> I guess your proposal was much more conservative.
Correct, I was only referring to the case where a PMC is a
String holding a method name -- I've not really come across that
as being a common case in the programming that I do.
Of the three cases given above, the only one that really looks
ambiguous to me is the first one, because methodname could be
either a bareword string or as a locally defined symbol. For
all the PIR code I work with I've been slowly-but-surely
converting any instances of the first to either explicitly
use quotes on the method name or (much less frequently)
explicitly use a $P register.
Based on an informal frequency analysis of the PIR I've written
by hand (as well as the syntax used by other OO languages
I typically frequent), it would seem that it would be preferable
to have
object.methodname()
as always meaning
object.'methodname'()
and that special syntax characters be used for the case where
we're invoking a method by something other than a constant string
name.
object.$P0() # invoke method $P0 on object
object.$S0() # invoke method named $S0 on object
object.??methodname() # left as an exercise for the architect to
decide what should go in place of '??'
Pm
