On Sep-01, Leopold Toetsch wrote: > Below is a pod document describing some IMHO worthwhile changes. I hope > I didn't miss some issues that could inhibit the implementation.
Overall, I like it, although I'm sure I haven't thought of all of the repercussions. The one part that concerns me is the loss of the flags -- flags just seem generally useful for a number of things. In the limit, each flag could be replaced by an equivalent vtable entry that just returned true or false, but that will only work for rarely-used flags due to the extra levels of indirection. I suppose we could also have a large class of PMCs that contained a flag word, and only the primitive PMCs would lack it, but then the flags cannot be used without knowing the type of PMC. It all comes down to the specific current and future uses of flags. You've dealt with the GC flags; what about the rest? The proposal would also expand the size of the vtable by a bit due to the string vtable stuff. I don't know how much that is, percentage-wise. And I suppose that increase is dwarfed by the decrease due to eliminating the S variants. (Although that's another part of the proposal that makes me nervous -- will MMD really take care of all of the places where we care that we're going to a string, specifically, rather than any other random PMC type? Strings are a pretty widespread concept throughout the code base, and this is the only highly user-visible part of the change.) I also view the proposal as being comprised of several fairly independent pieces. Something like: * Merging PMCs and Buffers * Merging STRINGs and PMCs * Removing GC-related flags and moving them to GC implementations * Removing the rest of the flags * Using Null instead of Undef * Moving "extra" stuff to before the PMC pointer * Using Refs to expand PMCs * Using DOD to remove the Ref indirection * Shrinking the base PMC size ..and whatever else I forgot. Not all of these are dependent on each other, and could be implemented separately. And some are only dependent in the sense that you'll make space or time performance worse until you make the rest of the related changes. You could call those design-dependent, rather than implementation-dependent.
