[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl6-internals
Subject:    Re: [perl #47972] [DEPRECATED] getclass opcode
From:       Allison Randal <allison () perl ! org>
Date:       2007-11-30 16:27:13
Message-ID: 475039E1.50103 () perl ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]