[antlr-interest] On trees and JavaBeans, part 2: tree creation

[Micheal J]

Scott,

> > > > The trouble is there are extra objects to collect. More
> > objects ==
> > > > more
> > > 
> > > You miss the point.
> > 
> > Yes he does. A TreeModel-style abstraction isn't an
> > alternative to the Carrier/Payload model. It is a façade that 
> > allows one to use Carrier/Payload or any other model one 
> > cares to implement.
> 
> I assume you mean Loring missed the point? Sometimes the 
> indentation is weird...

No, I meant you  ;-)

Your comment that there are extra/more objects to collect in the
Carrier/Payload model misses the point because:
(a) TreeModel-style abstraction is only an adapter - it doesn't remove the
need for an actual tree representation which may be a Carrier/Payload model.
(b) Carrier and Payload are interfaces - they may be implemented by the same
object instance hence no extraneous GC.

> > > There is less manipulation of data
> > > pointers with Payloads implemented as objects distinct from
> > Carriers
> > > when doing significant manipulations.  Objects created and
> > destroyed
> > > are homogeneous, which places less stress on the garbage collector
> > > resulting in faster creation times and fewer compactions. 
>  And, for 
> > > platforms that do not have efficient garbage collectors, 
> releasing 
> > > Carriers back to a CarrierFactory is possible.
> > 
> > Indeed.
> 
> But not necessary.
> 
> Pooling is nice, but adds a *ton* of complexity and potential 
> bugs (especially b/c it's way too easy to forget to release 
> loaned objects, resulting in a leak...)

I understand Loring to be recommending pooling (via a CarrierFactory) only
on platforms that do not have an efficient GC system. This is necessary and
once again, I'd argue that the benefits (in performance this time) outweighs
the [implementation and usage] cost of the pools.

> It’s much better to not have to create those extra 
> unnecessary objects in the first place.

If by "unnecessary objects" you meant CarrierFactory objects then see
comment above.

If however, you meant Carrier objects then please explain how you might
implement an structure that represents trees and separates navigation from
data. IOW, explain how you might design an alternative tree structure that a
TreeModel-style interface can adapt.

Even Eclipse's AST types follow the Carrier/Payload model in some sense. 

Cheers,

Micheal