jerry gay wrote:
>>
> but C does *not* work.
> i find that annoying.
> either make the syntax for methods different than ops (eg C<$S0.say()>)
> or make C an opcode,
> or dodge the syntax issue and make C a method on all register types.
>
> forcing me to convert the int to a string in order to aut
On Fri, Aug 25, 2006 at 03:32:12PM -0400, Will Coleda wrote:
> What about 'say'? It's a method, not an opcode, and:
> say $S0
> works just fine.
Well, 'say' is a parrotio METHOD, not a String METHOD:
METHOD INTVAL say(STRING *s)
so the SELF is an io PMC and nothing is hard. Expressing to_
On 8/25/06, Will Coleda <[EMAIL PROTECTED]> wrote:
What about 'say'? It's a method, not an opcode, and:
say $S0
works just fine.
but C does *not* work.
i find that annoying.
either make the syntax for methods different than ops (eg C<$S0.say()>)
or make C an opcode,
or dodge the syntax issue
What about 'say'? It's a method, not an opcode, and:
say $S0
works just fine.
I don't think there's *a priori* a problem to implicitly upgrade
something to a PMC to perform a non JIT-able task on it. I do think
pulling too hard at this thread might require a closer look at what's
current
(For those not watching CVS, Leo's just added a METHOD to_int() to String.)
Seems like this is the kind of thing that needs to have a common subroutine
in the C source so it can be used elsewhere, and an opcode so it's usable
with an S register. And once you've done that, the METHOD becomes redun
