PMC methods?
Luke Palmer
on them without getting ideas related to the general design. Not that
any of them have worked their way in (yet), but... :-)
Anyway, I was wondering how to, say, set upper and lower bounds on a
Range pmc. And then also how Socket IO might be worked in without
adding even more ops. So here's an idea. I'm not sure whether it's a
good idea yet.
Instead of having a bunch of specialized ops made for
constructing/working on specific pmcs, have, say, four general-purpose
ops whose meaning could be given by each pmc that uses them. So,
instead of, for instance, newsub, we'd make a new .Sub pmc and call
the pmc1 op on it with the label. For a socket pmc, we'd call pmc1 to
set the port, pmc2 to set the protocol, etc.
It's like a pmc having its own methods which relate to the pmc itself,
not the data it carries. It drops the method lookup overhead for
these less-dynamic more-internal sorts of things.
There are obviously problems with encapsulation here. I would deem
these "constructor-helpers", because they're pretty useless unless you
know exactly what kind of pmc you're dealing with.
And it would make the assembly a bit less easy to read and write,
having to consult a table for the pmc. But that's assembly, and I
don't think it was a long term goal to make it easy to write in
assembly.
Anyway, does this have a pinch of merit?
Luke
Sean O'Rourke
> Instead of having a bunch of specialized ops made for
> constructing/working on specific pmcs, have, say, four general-purpose
> ops whose meaning could be given by each pmc that uses them. So,
> instead of, for instance, newsub, we'd make a new .Sub pmc and call
> the pmc1 op on it with the label. For a socket pmc, we'd call pmc1 to
> set the port, pmc2 to set the protocol, etc.
One problem with this is that it hides errors, since you can
mistakenly send a message to a different type of PMC and still have it
be legal. How much do you think this would save over doing a single
findmethod and caching the result?
On the other hand, the profusion of special-purpose ops has been
bothering me as well. I'm not sure where we're drawing the line
between ops and methods. For example, should socket operations be
ops, or methods on a core Socket PMC? I think the latter, but only
because sockets don't seem as "core" as addition, not for any
principled reason. Another example: why does interpinfo exist, rather
than the interpreter just looking like a hash or array and using the
standard keyed get/set ops?
Do others (Dan? Juergen? Leo?) have some stronger sense of what
should and shouldn't be an op?
/s
Leopold Toetsch
> On 23 Jul 2003, Luke Palmer wrote:
>
>>Instead of having a bunch of specialized ops made for
>>constructing/working on specific pmcs, have, say, four general-purpose
>>ops whose meaning could be given by each pmc that uses them.
> ... For example, should socket operations be
> ops, or methods on a core Socket PMC? I think the latter, but only
> because sockets don't seem as "core" as addition, not for any
> principled reason.
Juergen Boemmels already has provided a patch, that allows calling
methods on IO objects. Though there was no discussion on that and its
not applied.
>Another example: why does interpinfo exist,
interpinfo is already obsoleted by my additions to ParrotInterpreter.
>
> Do others (Dan? Juergen? Leo?) have some stronger sense of what
> should and shouldn't be an op?
Common operations and all time critical stuff should be ops. Special
functionality (like interpinfo) or IO is IMHO better done as methods.
>
> /s
leo