Re: PDD17 - PMCs

[Allison Randal]

Leopold Toetsch wrote:

This implies (for me), that whatever silly morph requests like above would be 
issued, a PMC always has the needs of 'one size fits all'. This will preclude 
any optimzations of creating smaller spezialised PMCs as well as it seems to 
going the "PMC_data indirection hell" forever, with all the negative impacts 
on internal code readability and visible performance.

Yes, in the end, the proposal for variable sized PMC header structs 
didn't offer enough advantages to be worth losing the memory management 
optimizations possible with the current fixed-size PMC header structs. 
With this path, we do lose the ability to make a PMC that consists of 
nothing but the PMC flags and a single bit. But, that's a rare need, and 
only likely to be used by a few applications. Memory management, on the 
other hand, touches all applications that run on Parrot, so it's a more 
important target for optimization.

And yes, PDD17 does encourage the use of the 'data' struct element. With 
the shift to generating the data struct of attributes for each PMC, 
generating accessor macros for the members of that struct (SET_ATTR_* 
and GET_ATTR_*), and generating other meta-information introspectable at 
runtime, using 'data' consistently significantly improves the 
readability of the code, makes composition at the C level possible, and 
makes inheritance from a low-level PMC to a high-level PMC much, much 
cleaner.

Allison