incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: [PORTAL] Changes and API review?
Date Wed, 20 Dec 2006 01:44:09 GMT

EVERYTHING will have to cast to it, since the entry point does not 
return this class, but it's Configurator equivalent.  Reflection and 
casting are among the slowest operations in the Java language.  And, we 
do need access to this from the API package as well as the Impl (unless 
you want me to move the resource servlet to the impl).  These are facts.

Can it be done?  Yes.  But it's really ugly.  So I'll tell you what.  
I'll make an additional patch for this.  Take a look at both and you 
decide which is superior.


Adam Winer wrote:
> Scott,
> You're explaining very well why you want to put this in IMPL.
> And why you need a different instance that handles this on
> behalf of all other configurators.  You're not yet explaining
> why you need a whole class to accomplish this, as opposed
> to a standard decorator or CoR pattern, etc.  I just don't get it.
> This one global instance is going to load all other instances,
> and invoke all other instances.  NO ONE needs to cast to it -
> it is all powerful since it is the first (and only) entry point,
> and it can decide whether all the others will run or not.
> (And "dog slow"?  C'mon, you're exaggerating.  Hugely.
> And describing one potential implementation of one
> potential design.)
> Yes, I do fight against adding extra code to our
> API.  For good reason, ya know!  Less public API is
> good.  And, it really worries me when I see a design
> that is unlike all the other designs I've seen for this
> sort of pattern.  I immediately get a gut feeling that
> it's not really necessary.
> -- Adam

View raw message