12 Apr 2010 10:39 AM #11
Xtypes can be (as usual) a useful thing ... or not.
If you (a) might create a bunch of instances of "a thing," but (b) don't really know if you're going to need to do so or not ... then XTypes might well be the cat's meow.
When you declare an XType, one instance of the object is always created so that it can be associated with the type-name in the hash. The benefit then comes from being able to coin any number of copies of that object, just by cloning what is already in memory.
This is not the same as a system which would create the first object-instance only on-demand.
It is, therefore, "a practical system, but not entirely without cost." Know how it works, then "ask your doctor..."
12 Apr 2010 3:31 PM #12
- Join Date
- Jan 2009
- Palo Alto, California
- Vote Rating
The type registration pattern is one which occurs quite frequently - for example in 3.x the ComponentMgr is actually managing two types of object - Components and Plugins.
These two can be split apart into 2 separate Managers (while maintaining backwards compatibility) and the common Manager functionality abstracted up to a Manager class. This is very much on the radar and is something I'm actively investigating. The pattern can be applied in other areas also.
16 Apr 2010 6:15 AM #13
One "cheap trick" solution that just might work is to allow the XType to be associated with a closure that returns a type-instance.
When instantiating the type, the code would check to see if the associated object is a function. If so, it would be called, and the result would (say, unconditionally...) now replace the function itself. (The closure, its life's work done, would now vanish forever into the gloom...) From now on the code would work as it does now, creating a new instance of the memory-object.
Plainly, the first thing to determine is whether or not this approach would actually yield benefits of time and memory. It might not be possible. It might not do any good if it is. And BTW, I'm not "signing-up" to do it...