On Thu Nov 29 22:08:11 2007, [EMAIL PROTECTED] 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;
> >
> > There are currently 42 of these automagic translations (found in
> > src/builtins.c)
> >
> > 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'. 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. But
> the new I/O model is scheduled for completed implementation in May, and
> it'd be nice to remove 'getclass' before then.
>
> 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.
>
> Allison
>
In order to facilitate the removal of the getclass opcode, I've created a
branch
"no_builtin_methods" to experiment with removing the special translation that
exists for
many methods on builtin PMCs and, if necessary, replacing them with actual
opcodes.
(Especially the 'say' variants.)
--
Will "Coke" Coleda
