You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by kgignatyev <kg...@yahoo.com> on 2004/12/27 20:38:33 UTC
Why constructor requires parameters?
Why HiveMind requires constructor parameters if there is only one
constructor, or only one constructor that might be satisfied with
services from the repository?
Kind of contradictory to "Less is MORE" ideology.
Could HiveMind in version 1.1 adopt something like Pico's use of
getGreediestSatisfiableConstructor()?
http://www.picocontainer.org/versions/1.1/apidocs/org/picocontainer/defaults/InstantiatingComponentAdapter.html#getGreediestSatisfiableConstructor(org.picocontainer.PicoContainer)
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
The interface vs. pojo argument rages on.
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
>>For me, part of the distinction between an object (a POJO, a bean,
>>whatever name you like) and a service is that a service implements an
>>interface.
IMO From a user standpoint service is that I get from a factory and a
POJO, a bean, whatever is that I create with new keyword myself.
How about such a distinction?
>>Services will have a more complex life cycle, and can be intercepted,
>>and can be instantiated on first use (rather than first reference).
It could be applied to classes if they implement lifecycle interface (for extensive cleanup/startup),
or subclass might implement lifecycle interface automatically.
>>It is true that you can "intercept" a class, creating a proxy that's
>>really a subclass, with every method overridden in some way. That how
>>EasyMock Class Externsion works, but I'm dubious. Forces you to use
>>bytecode enhancement to do interception, rather than JDK proxies.
I would not say that subclass based approach forces bytecode manipulation, although it might be easiest and most
performant approach if based on CGLIB ( see performance estimations at http://kgionline.com/articles/aop_1/aop_perf.jsp ).
Alternative to bytecode machinations :) might be good old code generation. Which might well happen on the fly as long
as runtime has access to the java compiler.
Howard Lewis Ship wrote:
>The interface vs. pojo argument rages on.
>
>I hope, in 3.1, to have a way of building POJOs using something like
>BuilderFactory. One name for these is "resources", I kind of prefer
>"beans" ... distrinct from services.
>
>Services will have a more complex life cycle, and can be intercepted,
>and can be instantiated on first use (rather than first reference).
>
>It is true that you can "intercept" a class, creating a proxy that's
>really a subclass, with every method overriden in some way. That how
>EasyMock Class Externsion works, but I'm dubious. Forces you to use
>bytecode enhancement to do interception, rather than JDK proxies.
>
>For me, part of the distinction between an object (a POJO, a bean,
>whatever name you like) and a service is that a service implements an
>interface.
>
>
>On Tue, 28 Dec 2004 09:55:04 -0600, kgignatyev <kg...@yahoo.com> wrote:
>
>
>>Cool!
>>
>>How about another thing: making Interface optional? I am all for
>>encouraging of the good design, but enforcing it at the price of lessen
>>convenience does not seem right.
>>
>>Less is MORE!
>>
>>And the simplest thing that works is the class itself, when HiveMind
>>factory is used to obtain object instance it should not be different for
>>the rest of application if it returns an implementation of the interface
>>or a subclass that wraps its parent with necessary interceptors.
>>
>>If a need for the class to be an interface will arise (multiple
>>implementations, mocks, etc.), it could be easily done with refactoring:
>>the class becomes interface and interface class parameter will appear in
>>HiveMing factory definition. That should not affect rest of application
>>at all.
>>
>>Also: see http://picocontainer.org/Two+minute+tutorial when a class
>>gets registered in Pico with
>>pico.registerComponentImplementation(Boy.class); it could be retrieved
>>by its interface Kissable. Having such a feature in HiveMind would not
>>hurt IMO
>>
>>
>>Howard Lewis Ship wrote:
>>
>>
>>
>>>Knut agrees; he's added some much smarter code to HiveMind's
>>>BuilderFactory that works darn hard to find the right constructor and
>>>provide it with the correct parameters.
>>>
>>>
>>>On Mon, 27 Dec 2004 13:38:33 -0600, kgignatyev <kg...@yahoo.com> wrote:
>>>
>>>
>>>
>>>
>>>>Why HiveMind requires constructor parameters if there is only one
>>>>constructor, or only one constructor that might be satisfied with
>>>>services from the repository?
>>>>Kind of contradictory to "Less is MORE" ideology.
>>>>
>>>>Could HiveMind in version 1.1 adopt something like Pico's use of
>>>>getGreediestSatisfiableConstructor()?
>>>>
>>>>http://www.picocontainer.org/versions/1.1/apidocs/org/picocontainer/defaults/InstantiatingComponentAdapter.html#getGreediestSatisfiableConstructor(org.picocontainer.PicoContainer)
>>>>
>>>>--
>>>>Thanks,
>>>>
>>>>Konstantin Ignatyev
>>>>
>>>>http://www.kgionline.com
>>>>
>>>>PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
>>>>
>>>>Bowers, C.A. The Culture of Denial:
>>>>Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
>>>>New York: State University of New York Press, 1997: (4) (5) (p.206)
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>Thanks,
>>
>>Konstantin Ignatyev
>>
>>http://www.kgionline.com
>>
>>PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
>>
>>Bowers, C.A. The Culture of Denial:
>>Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
>>New York: State University of New York Press, 1997: (4) (5) (p.206)
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Why constructor requires parameters?
Posted by Howard Lewis Ship <hl...@gmail.com>.
The interface vs. pojo argument rages on.
I hope, in 3.1, to have a way of building POJOs using something like
BuilderFactory. One name for these is "resources", I kind of prefer
"beans" ... distrinct from services.
Services will have a more complex life cycle, and can be intercepted,
and can be instantiated on first use (rather than first reference).
It is true that you can "intercept" a class, creating a proxy that's
really a subclass, with every method overriden in some way. That how
EasyMock Class Externsion works, but I'm dubious. Forces you to use
bytecode enhancement to do interception, rather than JDK proxies.
For me, part of the distinction between an object (a POJO, a bean,
whatever name you like) and a service is that a service implements an
interface.
On Tue, 28 Dec 2004 09:55:04 -0600, kgignatyev <kg...@yahoo.com> wrote:
> Cool!
>
> How about another thing: making Interface optional? I am all for
> encouraging of the good design, but enforcing it at the price of lessen
> convenience does not seem right.
>
> Less is MORE!
>
> And the simplest thing that works is the class itself, when HiveMind
> factory is used to obtain object instance it should not be different for
> the rest of application if it returns an implementation of the interface
> or a subclass that wraps its parent with necessary interceptors.
>
> If a need for the class to be an interface will arise (multiple
> implementations, mocks, etc.), it could be easily done with refactoring:
> the class becomes interface and interface class parameter will appear in
> HiveMing factory definition. That should not affect rest of application
> at all.
>
> Also: see http://picocontainer.org/Two+minute+tutorial when a class
> gets registered in Pico with
> pico.registerComponentImplementation(Boy.class); it could be retrieved
> by its interface Kissable. Having such a feature in HiveMind would not
> hurt IMO
>
>
> Howard Lewis Ship wrote:
>
> >Knut agrees; he's added some much smarter code to HiveMind's
> >BuilderFactory that works darn hard to find the right constructor and
> >provide it with the correct parameters.
> >
> >
> >On Mon, 27 Dec 2004 13:38:33 -0600, kgignatyev <kg...@yahoo.com> wrote:
> >
> >
> >>Why HiveMind requires constructor parameters if there is only one
> >>constructor, or only one constructor that might be satisfied with
> >>services from the repository?
> >>Kind of contradictory to "Less is MORE" ideology.
> >>
> >>Could HiveMind in version 1.1 adopt something like Pico's use of
> >>getGreediestSatisfiableConstructor()?
> >>
> >> http://www.picocontainer.org/versions/1.1/apidocs/org/picocontainer/defaults/InstantiatingComponentAdapter.html#getGreediestSatisfiableConstructor(org.picocontainer.PicoContainer)
> >>
> >>--
> >>Thanks,
> >>
> >>Konstantin Ignatyev
> >>
> >>http://www.kgionline.com
> >>
> >>PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
> >>
> >>Bowers, C.A. The Culture of Denial:
> >>Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
> >>New York: State University of New York Press, 1997: (4) (5) (p.206)
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> Thanks,
>
> Konstantin Ignatyev
>
> http://www.kgionline.com
>
> PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
>
> Bowers, C.A. The Culture of Denial:
> Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
> New York: State University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Why constructor requires parameters?
Posted by kgignatyev <kg...@yahoo.com>.
Cool!
How about another thing: making Interface optional? I am all for
encouraging of the good design, but enforcing it at the price of lessen
convenience does not seem right.
Less is MORE!
And the simplest thing that works is the class itself, when HiveMind
factory is used to obtain object instance it should not be different for
the rest of application if it returns an implementation of the interface
or a subclass that wraps its parent with necessary interceptors.
If a need for the class to be an interface will arise (multiple
implementations, mocks, etc.), it could be easily done with refactoring:
the class becomes interface and interface class parameter will appear in
HiveMing factory definition. That should not affect rest of application
at all.
Also: see http://picocontainer.org/Two+minute+tutorial when a class
gets registered in Pico with
pico.registerComponentImplementation(Boy.class); it could be retrieved
by its interface Kissable. Having such a feature in HiveMind would not
hurt IMO
Howard Lewis Ship wrote:
>Knut agrees; he's added some much smarter code to HiveMind's
>BuilderFactory that works darn hard to find the right constructor and
>provide it with the correct parameters.
>
>
>On Mon, 27 Dec 2004 13:38:33 -0600, kgignatyev <kg...@yahoo.com> wrote:
>
>
>>Why HiveMind requires constructor parameters if there is only one
>>constructor, or only one constructor that might be satisfied with
>>services from the repository?
>>Kind of contradictory to "Less is MORE" ideology.
>>
>>Could HiveMind in version 1.1 adopt something like Pico's use of
>>getGreediestSatisfiableConstructor()?
>>
>> http://www.picocontainer.org/versions/1.1/apidocs/org/picocontainer/defaults/InstantiatingComponentAdapter.html#getGreediestSatisfiableConstructor(org.picocontainer.PicoContainer)
>>
>>--
>>Thanks,
>>
>>Konstantin Ignatyev
>>
>>http://www.kgionline.com
>>
>>PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
>>
>>Bowers, C.A. The Culture of Denial:
>>Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
>>New York: State University of New York Press, 1997: (4) (5) (p.206)
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Why constructor requires parameters?
Posted by Howard Lewis Ship <hl...@gmail.com>.
Knut agrees; he's added some much smarter code to HiveMind's
BuilderFactory that works darn hard to find the right constructor and
provide it with the correct parameters.
On Mon, 27 Dec 2004 13:38:33 -0600, kgignatyev <kg...@yahoo.com> wrote:
> Why HiveMind requires constructor parameters if there is only one
> constructor, or only one constructor that might be satisfied with
> services from the repository?
> Kind of contradictory to "Less is MORE" ideology.
>
> Could HiveMind in version 1.1 adopt something like Pico's use of
> getGreediestSatisfiableConstructor()?
>
> http://www.picocontainer.org/versions/1.1/apidocs/org/picocontainer/defaults/InstantiatingComponentAdapter.html#getGreediestSatisfiableConstructor(org.picocontainer.PicoContainer)
>
> --
> Thanks,
>
> Konstantin Ignatyev
>
> http://www.kgionline.com
>
> PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
>
> Bowers, C.A. The Culture of Denial:
> Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
> New York: State University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org