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. 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
