On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Tue, 22 Jun 2004, Leopold Toetsch wrote:
>
> >> old_limit = $P0."recursion_limit"(new_limit)
>
> > That's fine. We should add this (and anything else we do this way) to the
> > interpinfo op so the values can be fetched back out, both by bytecode and
> > via the interpinfo call for C code.. I'm tempted to have a special op for
> > setting interpreter values rather than rely on methods, since this is all
> > very low level, and likely to be set via C code. (Where method calls into
> > parrot are a bit of a pain)
>
> I think that this won't get used heavily. Anyway for this case, we can
> integrate it into C<interpinfo> or some such.
It won't be heavily used, certainly, but it will get used by folks doing
embedded work. (They're the most likely users of this stuff, really)
> OTOH we probably need to support a method interface for a lot more
> things. b3.py has stuff like: TT.__cmp = Integer.__cmp, where TT is a
> ParrotClass and Integer isa PMC.
The current method interface for this sort of thing's fine. We may want to
jump through some hoops with default MMD dispatch for some of these things
(which is what the above code does -- __cmp gets mapped to one of the cmp
slots) as it'll get... fun, but shouldn't be too big a deal.
The underlying python bytecode doesn't make method calls by default for
__cmp and friends unless they're overridden. (Which they are there, of
course, but...) A standard left-side-wins scheme with operator
overloading's in place for 'em.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
