I've been looking at Bob's code in more detail and the insight is revealing
when compared to the base constructs of the DynAPI. The first thing I
noticed is his use of interfaces, inner classes and upcasting (very Java,
C++ ish) in the creation of Objects. This allows a little distance between
the object constructor and it's parent.
> http://www.mindspring.com/~bobclary/base/docs/xbObject.html site of
xbObject.
Then he leverages this by explicitly creating object deconstruction that is
callable and reverse chains up to it's parent to allow full nulling of the
object to allow for garbage collection. In other words, he created a very
clever form of garbage collection within the class constructors themselves.
With the DynAPI we tend to be a level flatter and without the ability to
explicitly call "object destroy" since we assume that the JS GC will
naturally clean up our mess, probably a mistake on our part. Also, since we
are a level shorter in hierarchical height we also are having problems
creating a natural "object clip point" to allow us to effectively "throw the
used object away" and have the GC actually pick it up.
This "added object tier" structure had been tickling the back of my brain
lately as I consumed mass quantities of Java. The question now is how easy
will it be for us to reverse engineer explicit garbage collection (on a
clipable reference object level) into the current DynAPI as this will
probably solve the current GC issues.
Laters
Ray
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
