Hi,

some days ago near #parrot:

17:13 <particle> if you get a chance, allison has modified pdd17 (pmc). i'm 
reviewing it, but i think you'd be a better judge of its implications on gc, 
etc.
17:14 <leo> I'll have a look at it - thx

Well, xx days after, I had a very brief look at it:

- it's mostly a summary of current state
- some new good things (roles) are defined, which aren't yet in src/role/
- the old "bugs", which IMHO, a rigid PMC structure and morph are, are still 
present:

...
IMPLEMENTATION
       Internal structure
       All PMCs have the form:
...
       morph
             void morph(INTERP, PMC* self, INTVAL type)

           Turn the PMC into a PMC of type type. If the morphing can't be done 
in any reasonable way -- for instance if an integer is
           asked to turn into an Array -- then the PMC is first destroyed, 
then recreated as an empty PMC of the new type.


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.

I'm sorry if I've misunterstood this document,
leo

Reply via email to