On Fri, Nov 30, 2007 at 08:07:30AM +0200, Allison Randal wrote:
> Will Coleda wrote:
> >1) using getclass (aka, reject this ticket)
> >2) doing something custom for the say method here (like, say,
> >translating say 'what' into something like "getstdout P0;
> >P0.'say'('what');"
> >3) eliminating the automagic method translation used here and just
> >writing a 'say' opcode.
> >4) find a syntax that works generically like the current method does;
> >
> >What's the desired approach here? I'd prefer 4 slightly over 3; neither
> >requires a deprecation cycle (unless as part of 3 we decide to not
> >support opcodes/faux-opcodes for some of them.); 2 is evil. I am neutral
> >on 1.
>
> Another alternative is to update ParrotIO so it works with the new
> 'get_class'.
The problem isn't so much with ParrotIO as it is with the way that
'say' is implemented. Say expects to be able to get the ParrotIO
class object and invoke the 'say' method on it -- but this is no
longer valid under pdd15 objects, where the class methods are no
longer available via the class object.
$P0 = getclass 'ParrotIO'
$P0.'say'('hello') # works
$P1 = get_class 'ParrotIO' # actually gets a ProxyPMC
$P1.'say'('hello') # fails
> ... That change is in the works, I/O will be integrated into
> the new OO model, instead of using its own custom OO-like system.
If I'm reading this correctly, I'm guessing that means that there
would be pre-defined objects somewhere for stdout, stdin, stderr.
If that's the case, this would seem to argue for approach #2, or
something like it -- i.e., grab the object corresponding to stdout
and do something with it.
> I'm in favor of making 'say' a standard opcode, whatever else we do.
> That is, assuming it's worth keeping. Show of hands if you use it and
> want to keep it.
The 'say' opcode is incredibly useful, and I use it a lot.
I raise both my hands in favor of keeping it.
As far as my opinions to the four items in Coke's list... I like
#1 the least and #3 the best. There's also a fifth option,
which would be something like:
5) Have every class automatically create a protoobject and let
'say' and the other similar opcodes be able to access methods
via the protoobject. We might even introduce a new opcode:
$P0 = get_proto 'ParrotIO'
$P0.'say'('hello')
But I'd venture to wait for other tools to mature a bit before
committing to protoobjects in the parrot core. So, even with
option #5, I think I'd prefer to go with something like #3 for
the time being. IMO the majority of the other builtins aren't
important enough for their own opcode syntax -- we can just
use the method syntax instead.
Pm
