Gee, doing these lazy pmcs is great. Seems I can't get any work done 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
