Steve Fink <[EMAIL PROTECTED]> wrote: > 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, I'm not thinking about vtable entries returning a flag bit. E.g. the presence of PObj_custom_mark_FLAG could as well be tested as: if (pmc->vtable->mark) // != NULL Generally speaking the vtable mostly holds the information, that is needed for one kind of PMC. More specialized PMCs can have their private flags (for example a Key PMC). But they are normally not needed. An Integer or Float PMC doesn't need any flags to perform its operation. The proposed scheme doesn't of course forbid private flags in the PMCs data section. But a lot of PMCs just don't need any flags. > The proposal would also expand the size of the vtable by a bit due to > the string vtable stuff. No. The vtable would very likely shrink. 46 vtable (or MMD) entries are currently used by STRING* operations. These would be just PMC operations, which we have anyway. > ... 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? MMDs have to deal with that anyway. We have String PMCs. The vtables or MMD functions that currently take STRING* ought to be optimized shortcuts for STRING* arguments. But if a String PMC is passes, still The Rigth Thing has to happen. > I also view the proposal as being comprised of several fairly > independent pieces. Something like: * allow/allocate variable sized PMCs Then --yes. > * Merging PMCs and Buffers > * Merging STRINGs and PMCs That's the same thing, mostly. > * Removing GC-related flags and moving them to GC implementations We already have that. But it's not hidden or encapsulated. > * Removing the rest of the flags Yep. > * Using Null instead of Undef No. Undef is a totally different thing. There is no change here. The Null PMC catches program errors (like using a C NULL pointer). The Undef is just a placeholder that morphs to any other type. > * 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 Yep. That is related. though. > ... 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. Yes. leo
