RFC: Adding an alternative dispatch mechanism

Austin Hastings ah08010-d at yahoo.com
Fri Oct 1 14:00:39 PDT 2010


Howdy,

One of the design patterns that doesn't see much publicity in the 
mainstream is the Flyweight pattern.

To save you a trip, Flyweight basically implements large numbers of 
virtual objects - an array of bits, for example, is usually implemented 
via this pattern.

Iould be nice to be able to dodge the relatively high "object tax" for 
small objects, without having to sacrifice all the features that 
switching from class to struct requires. That is, if each object stores 
a vtable, then a class with a single int member pays a 32bit tax on 
32bits of storage, and I suppose 64bits of tax on 32bits of storage in 
64-bit land.

Obviously, this eventually fades away - your 1kbyte uberclass probably 
isn't bothered by the tax. But I've got some 2-byte data that isn't 
about to become a class, for obvious reasons.

Anyway, I'd very much like to preserve the ability to derive subclasses. 
This isn't about converting to struct, but about ways to lower the cost 
of being an object.

To that end, I'd like to propose a sort of opVtable - name obviously 
subject to change - that would somehow report the class of the target 
object, thus enabling virtual function dispatch.

This would be static type based, so if you have a reference to a 
BaseClass, then obviously the call will go to BaseClass.opVtable for 
resolution.

But there are lots of ways to encode type info, so BaseClass could 
implement a trivial approach - all children get the same vtable (this is 
Flyweight, really) - or BaseClass could use some characteristic of the 
target object to determine a child class.

This is for the most part syntactic sugar. But it's pretty powerful 
sugar, since there are some edge cases (the object reference is the 
data) where the amount of code-around to get the same result is pretty high.

As a thinking point, consider UTF-8 "character" sequences. The objects 
are variable sized, and benefit strongly from being closely packed. I 
don't think anyone wants to insert 32 bits of pointer at the front of 
each sequence :).  But there are a LOT of different questions one might 
ask about a UTF8 "object" - is it lower case? what is the upper case 
version? is it in character class 'X'?

A simple implementation would use opVtable to decode enough for size and 
code page info, then proceed from there. The result would be that each 
pointer into a buffer was effectively an object pointer.

Comments?

=Austin


More information about the Digitalmars-d mailing list