Re: [Somewhat OT] Code organization question
Re: [Somewhat OT] Code organization question
- Subject: Re: [Somewhat OT] Code organization question
- From: Lachlan Deck <email@hidden>
- Date: Fri, 27 Mar 2009 04:53:32 +1100
Does lazy instantiating for each prop work?
On 26/03/2009, at 3:52 AM, Stamenkovic Florijan wrote:
Hi all,
Not a strictly WO question, but what the heck :)
I am working on moving JBND derived prop management to DataTypes
(JBND's view of class descriptions), for various reasons. In
principle I am done, and it works great. However, I am faced with
the problem of initializing those derived prop definitions. They
need to be initialized once per class, before any KVC takes place.
Doing this properly is a pain. My first idea of doing a static block
per-class:
static{
// initialize stuff
}
...does not work. It causes a JC specific exception because it makes
a circular class loading situation. So, I switch to something like:
public static void initDerivedProps(){
// initialize stuff
}
This works, but it requires that the method be externally called,
once per class that contains derived props. This is a maintenance
pain (and makes me think about the concept of abstract static
methods). Anyway, I've come up with putting the following in my EO
superclass:
private static final Set<Class<?>> initializedDerivedProps = new
HashSet()...;
// the EO superclass constructor
protected EOFDataObject(...){
if( ! initializedDerivedProps.contains(getClass()){
initDerivedProps();
initializedDerivedProps.add(getClass());
}
...
}
// not static, but called only once per class
protected initDerivedProps(){
// initialize stuff
}
I didn't try this out yet, but I think it should do what I want it
to. There are however two problems with it. One: it causes a
HashSet.contains(Class) call once per EO instantiation. Not a large
overhead, but it's annoying. Two: it's an ugly hack... So, I'm
wondering if anyone else has an idea for a better approach?
Thx,
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden