commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] extend BuildFactory to use static fields/methods
Date Wed, 01 Oct 2003 13:37:37 GMT
Outside of Kurt's use case ... wrapping around machine-generated code, I feel that this talk
of
accessing static singletons is a step backwards.

The point of HiveMind is to eliminate those static variables and static inits, do things thread-safe
and just-in-time.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk] 
> Sent: Wednesday, October 01, 2003 9:06 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] extend BuildFactory to use static 
> fields/methods
> 
> 
> Wouldn't the configuration passed to the factory will make sure the 
> service is returned in a 'usable' state?  The user doesn't do any 
> configuration at that level?
> And the service interface shouldn't really allow 
> configuration changes or?
> 
> And I am all for the pattern to ensure consistency in created 
> objects ... 
> Not sure if it applies here though ...
> 
> Johan
> 
> 
> On Wed, 01 Oct 2003 15:05:16 +0200, Christian Essl 
> <christianessl@yahoo.de> wrote:
> 
> > You are right HiveMind always returns the same instance, but I mean
> > there can be services which have no state or the state of 
> which is just 
> > defined at construction time and for these it makes in my 
> opinion sense 
> > to declare them as (default-variant) static fields. Further 
> for those 
> > Services the static field gives a level of indirection.
> >
> > But certainly the more intresting idea was the one of 
> static-factory-
> > methods. I personally hate nothing more than making a default 
> > constructor for classes which need external data to be 
> ready for usage. 
> > I don't want to construct my classes and than rely on the 
> user that he 
> > might set the needed data sometime . When a class is constructed it 
> > should be in a valid state or otherwise throw an Exception. 
> And as you 
> > know a pattern to ensure that is to use a 
> static-factory-method and a 
> > private (maybe protected) constructor.
> >
> > On Wed, 01 Oct 2003 14:29:49 +0200, Johan Lindquist 
> > <johan@kawoo.co.uk>
> > wrote:
> >
> >> I may have misunderstood this - but doesn't hivemind always return 
> >> the
> >> same instance when you ask for a service once it has created one 
> >> (unless it is a threaded service model, when you are worried about 
> >> state anyway and probably want different instances)?  If 
> so, what is 
> >> the need to have a static instance?  I suppose I can see a 
> use for it 
> >> to share data between threads, but the singleton service 
> should suffice?
> >>
> >> Johan
> >>
> >> On Wed, 01 Oct 2003 13:52:58 +0200, Christian Essl
> >> <christianessl@yahoo.de> wrote:
> >>
> >>> That's very good (and fast implemented). But do you realy 
> have to do
> >>> the double-check on the class. I mean the user sees 
> anyway what class 
> >>> it is from the JavaDoc and HiveMind will always check 
> that it fits the 
> >>> Service interface.
> >>>
> >>> Sure if the static field changes this ensures consistency, but on 
> >>> the
> >>> other hand it would be also very convient to change all services 
> >>> referenced but just changing the static field without the 
> need to go 
> >>> into the module.
> >>>
> >>>
> >>> On Wed, 1 Oct 2003 12:40:12 +0200, Knut Wannheden
> >>> <knut.wannheden@paranor.ch> wrote:
> >>>
> >>>> I have created a copy of the hivemind.BuilderFactory 
> service which
> >>>> allows me
> >>>> to write:
> >>>>
> >>>> <invoke-factory service-id="my.BuilderFactory">
> >>>> <construct class="foo.Bar" static-field="foo.Bar.INSTANCE"/> 
> >>>> </invoke-factory>
> >>>>
> >>>> given that I have something like:
> >>>>
> >>>> package foo;
> >>>> public interface Bar {
> >>>> static final INSTANCE = new BarImpl();
> >>>> }
> >>>>
> >>>> The class attribute is used to check that the object 
> specified by 
> >>>> the static-field is of a given type, which is an 
> interface in this 
> >>>> example.
> >>>>
> >>>> --knut
> >>>>
> >>>>> That's certainly a good idea.
> >>>>>
> >>>>> On Wed, 1 Oct 2003 07:50:42 +0200, Knut Wannheden 
> >>>>> <knut.wannheden@paranor.ch> wrote:
> >>>>>
> >>>>> > Hi,
> >>>>> >
> >>>>> > I was wondering whether it would make sense to extend the
> >>>>> BuildFactory
> >>>>> > service (or maybe add a new wervice) to also be able to 
> >>>>> > construct
> >>>> objects
> >>>>> > by
> >>>>> > returning the value of a classes static field or by calling
a
> >>>>> static
> >>>>> > method
> >>>>> > on a class. The former would obviously be simpler. E.g. (as
a 
> >>>>> > new
> >>>>> > service):
> >>>>> >
> >>>>> > <invoke-factory service-id="hivemind.StaticBuilderFactory">
> >>>>> > <construct class="foo.Bar" static-field="BAZ"> <set.../>
> >>>>> > </construct>
> >>>>> > </invoke-factory>
> >>>>> >
> >>>>> > --knut
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > 
> >>>>> 
> ------------------------------------------------------------------
> >>>>> ---
> >>>>> > To unsubscribe, e-mail: 
> >>>>> > commons-dev-unsubscribe@jakarta.apache.org
> >>>>> > For additional commands, e-mail: 
> >>>>> commons-dev-help@jakarta.apache.org
> >>>>> >
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Using M2, Opera's revolutionary e-mail client:
> >>>>> http://www.opera.com/m2/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 
> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: 
> commons-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 
> -- 
> you too?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message