At 11:55 AM +0200 5/30/04, Leopold Toetsch wrote:
What about the current implementation [1]:
Leo, you're missing the point pretty badly here
I don't think so. I've described a static scheme in terms of read-only PMCs.
1) static read-only layering
Needs one extra vtable per PMC. All mutating vtable entries point to a default read-only implementation that throws an exception. Non-mutating vtable slots point to that of the PMC.
1a) constant read-only is a special case of 1)
2) static thread-safe layering
Needs one extra vtable plus a thread-safe vtable function implementation for each non thread-safe operation per PMC.
3) dynamic layering
Your second scheme. Needs one wrapper PMC per layer type and a vtable slot to wrap the PMC.
E.g. The SharedRef PMC class is such a layer. It delegates vtable to the contained PMC and has LOCK()/UNLOCK() around the call. The wrapping is done by the vtable->share() function, which has to copy the PMCs data to the newly created one and swap vtables.
This adds one indirection to get the contained PMC plus one additional vtable call per layer. It's slower but uses less (mainly code) memory.
4) General purpose dynamic layering If we really need it, it's basically like 3)
The static scheme especially for read-only PMCs is simple. Its just "put in a different vtable".
Your scheme number one isn't usable - it would "move" the PMC.
leo
