Re: Good, free profiling?

hi,

> > >The basic types, such as String, Number, Boolean work fine.  It
> > >differentiates between mutable and immutable objects.  Immutable objects
> > >are
> > >String, Number, Boolean, java.util.Date (which is slightly fudging), Enum
> > >and anything marked as IImmutable (a new marker interface for immutable
> > >objects).
> > >
> > >Mutable objects are tougher since the persistance wants to keep an
> isolated
> > >copy of properties.  That is, fireObservedChange() results in a copy
> being
> > >made, and when a page is rolled back in a later request cycle, a copy (of
> > >the copy) is made.
> > >The problem is handling the copying of values.  At best, its going to do
> a
> > >shallow copy.  As a last resort, Serializable objects are serialized and
> > >deserialzed (to make a deep copy).

I think exposing the pooling that has to happen inside tapestry to the
average component developer is a mistake. It just opens up a way of
shooting yourself in the foot, while giving very little advantage to app
developers in general. And it seems now in order to make the semantics
less confusing, you have to add more expensive and complicated behavior
(copying) to the framework... Now I do agree that the pooling of
expensive resources (templates, bindings, whatever else) is a goood
thing... however, i would separate it in two: make components non-pooled
and recreated all the time, and separate out the heavyweight portion into
another class that does need to know about pooling. The lightweight
component should delegate to the pooled instance when needed (Tapestry
should estabilish the association between it and the peer).

eg. so a request could go somewhat like this:

Component c = ... // new instance
ComponentPeer p = pool.getPeer(c);
c.setPeer( p );
// perform request...
p.detach()
c = null; // just forget about it...
pool.returnPeer(p);

I think this would make developers have to think about a lot less
"issues" that really have nothing to do with their application logic,
only how the framework is built. Writing components would become more
natural - you can use regular constructors and forget about detach and
it's sideffects.

i hope this doesnt sound much sillier or less efficient than an intricate
copying solution with special handling for immutables :)

best regards,
    viktor
-- 
  
  [email protected]

-- 
http://fastmail.fm - Email service worth paying for. Try it for free


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf