Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <cc159a4a0601030706i46905afag562786ad8f3ddc0f@mail.gmail.com>
References: <A955EA1F8FE31749AEC8C998082F6C7C41A8B7@hai01.hippo.local>
 <43B9164F.5080201@apache.org> <43B95C08.8010602@dslextreme.com>
 <7557e99f0601020933xe119a58j588921935798ba63@mail.gmail.com>
 <43BA239A.5000200@apache.org> <43BA403D.7000701@apache.org>
 <Pine.LNX.4.64.0601031125000.8158@lapgp.otego.com>
 <cc159a4a0601030706i46905afag562786ad8f3ddc0f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EB3AA47F-4CAC-4EF5-9F40-A234C16F3A22@hard-bop.com>
Content-Transfer-Encoding: 7bit
From: Ezkovich Glen <glen@hard-bop.com>
Subject: Re: [RT] Simplifying component handling
Date: Tue, 3 Jan 2006 10:38:16 -0600
To: dev@cocoon.apache.org


On Jan 3, 2006, at 9:06 AM, Peter Hunsberger wrote:

> On 1/3/06, Giacomo Pati <giacomo@apache.org> wrote:
>>
>> I'm with Sylvain's and Gianugo's oppinion. I also see users getting
>> confused with multiple choices of "how to write a component". I'd  
>> say in
>> this area we need a revolution instead of an evolution.
>
> I really don't get this objection; if I see a class that allows
> constructor injection OR can be initialized via some other sequence
> I'm going to think "gee, that's nice, I can do everything in one shot
> instead of having to call the service manager" (or whatever) .  All
> that's required to make sure that's clear is about 2 lines of Javadoc
> on the constructor and if that's missing and someone does try to
> initialize the class both ways you can probably make sure it either
> blows up or handles things gracefully.
>
> We use constructor injection in some of our code.  It's clean, it's
> simple, it's easy to write.  Sometimes we support multiple methods of
> initializing the code. It's pretty darn clear what's going on to any
> user of the code. As a Cocoon user I really think that any objection
> to this proposal based on "it might be confusing to users" is bogus...

I agree. This is a minor simplification directed towards developers.  
If they can't figure out when and when not to use this then they need  
to learn. The fact that this buys you very little is a different  
concern. Sometimes we spend a bit more then we should for little  
luxuries, but we're willing to eat bread and water as a result. Just  
make sure Carsten is the one who suffers for this luxury ;)

Glen Ezkovich
HardBop Consulting
glen at hard-bop.com


A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to  
worry about answers."
- Thomas Pynchon Gravity's Rainbow