Patrick R. Michaud wrote:
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
Ah! I only had 5 minutes to look at it before running out the door to an
all-day meeting. Then the code could just change to:
$P1 = new 'ParrotIO'
$P1.'say'('hello')
and make the default ParrotIO object use STDOUT.
But, I'm still in favor of making 'say' an opcode instead. The I/O
subsystem is far too full of "special" solutions, so I'd like to
standardize it with the rest of Parrot wherever possible.
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.
There already are predefined objects, they're retrieved by the
getstdout, getstdin, and getstderr opcodes. (Which internally call
_PIO_STDOUT(interp), etc...)
Mainly I meant that I/O will use PMC inheritance and compile-time
composition instead of its current "layers".
The 'say' opcode is incredibly useful, and I use it a lot.
I raise both my hands in favor of keeping it.
Two votes is good enough for me. It stays.
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.
Agreed. Avoid the "special" solutions until they're absolutely necessary.
IMO the majority of the other builtins aren't
important enough for their own opcode syntax -- we can just
use the method syntax instead.
If they aren't worthy of their own opcode, are they worthy of the
builtin syntactic sugar?
Allison
