[Embedlets-dev] Re: Properties vs. instance variables

[Andrzej J. T. <an...@ch...>]

Chris comments:

>  hate... no I actually love, to harp on this. This is the issue that we
> went round and round on not so long ago. As I pointed out:
> 
> 1. Performance will suffer due to the variable lookup being in-line with
> mission critical code.
> 2. Programmers will be reluctant to make every variable access an indirect
> call to a context object. 
>3. The context Hastable becomes a thread contention
> item that has to be synchronized, bottle-necking multithreaded access (I did
> not point this out but it is a fact).

#1 can be a factor, as I found out.  However, this is only an impact on 
functions/embedlets that are exercised frequently (as is the event management 
code and the benchmark which tries to artificially pump as many events as is 
possible), which is why it had such a deleterious effect on the benchmark in 
particular.   Many Embedlets will not require this level of performance and 
will be called less frequently, so it won't be an issue.  I'm very reluctant 
to sacrifice simplicity/consistency on the alter of performance too early in 
the development/adoption curve, since performance is very much a relative 
thing and something that is in the eye of the beholder (ie. dependent on the 
application performance requirements).

#2 is definitely NOT true.  Servlets are the classic example.  Any persistent 
data is stored in the HTTPSession object, NOT in instance variables.  I think 
there is precedent for this sytle of component development.

#3 May be an issue at times.  I did some benchmarking and acquiring 
synchronization locks was not a big factor in the processing speed, even on a 
TINI.

> Reversing the roles so that the Context is only there to provide
> initialization properties and to transform/transport Embedlet properties
> only when needed, is the way to go, IMNSHO.

True enough, to some degree, though it comes at a price, that being that 
Embedlets have to be written to be thread safe, which is something that many 
developers have trouble with.  

Right now, the code base supports both paradigms.  What I think is needed 
(like the sync vs. async events issue) is a Usage Guidelines document that 
discusses the tradeoffs of one style of usage versus the other, and let the 
application developer choose which style is most suitable for their purposes 
(at least until we get real world feedback as to which is the most common 
usage pattern).  Best of both worlds to start....specialize later if need be.

In any case, when the next version goes up later this weekend, check out how 
I handled the "caching" of properties in instance variables (in the 
org.embedlet.Component base class).  Most were read only, initialization 
values, so that was trivial (they never change after startup).  The Lifecycle 
state value does get updated throughout the life of a component, and it was 
rather trivial to add this kind of "caching" on an "as required" basis.

> I am very impressed with the xRAD development process that you are
> demonstrating. Within a  couple of days, a critical issue was surfaced,
> diagnosed, addressed and fixed!
> 
> My hat off to you!

Thanks!  Comes with a lot of experience doing the same on commercial 
projects.  In fact, my new consulting gig is to do just that 
again....create/lead an agile project team to success.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com