Mailing-List: contact shiro-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: shiro-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: les.hazlewood@anjinllc.com
In-Reply-To: <BAY127-W25C5B58366DF9EC0B477B0AFFB0@phx.gbl>
References: <AANLkTim-gtDVlI-DBKmhZ_6RGBMDv124AVao2RgtxvQM@mail.gmail.com>
	 <AANLkTimCVl4rNpsi76DYzTrlsuWvjKwIP4x_mIOh-Bgu@mail.gmail.com>
	 <AANLkTikLBwmlwjqxccczuyFQ4UVet9QFT1yv8Qepf86z@mail.gmail.com>
	 <AANLkTikp7NE2Xd-nbmAwxm3e7br5IMHVGb1fWUqNesul@mail.gmail.com>
	 <AANLkTim-tkP8z9LOpphn2JLvpt8irQjHvpqBLrEiMO46@mail.gmail.com>
	 <BAY127-W25C5B58366DF9EC0B477B0AFFB0@phx.gbl>
Date: Wed, 12 May 2010 17:18:59 -0700
Message-ID: <AANLkTims-qby794ipPIMF0Iwi3fHtl9iJZ97nvoNvbDf@mail.gmail.com>
Subject: Re: r942498 - removing all convenience methods?
From: Les Hazlewood <lhazlewood@apache.org>
To: shiro-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ah - nice to see you jump in Bryan :)

You're right - the add/remove methods don't preclude getters and
setters - they could co-exist.  I was looking for consistency more
than anything across all properties - not *Registar/*Aware constructs
for some properties and not have it for the majority of others.  But
if the user community feels strongly about this, we can of course add
them later.  As you know, it is much easier to add after 1.0 than it
is to take away :)

Les

On Wed, May 12, 2010 at 4:29 PM, Bryan Turner <incommand@hotmail.com> wrote=
:
>
> I'd like to jump in on this and say that I think both approaches have val=
ue. There's little reason, in my opinion, why both can't be done. add/remov=
e methods do not necessarily preclude get/set methods; I think both should =
be in the code for these sorts of framework pieces.
> With regards to IoC and injection, I'll start by declaring my allegiance:=
 I _hate_ constructor injection and I remove it everywhere I can. That said=
, I recognize that is offers an _appearance_ of better safety and that it h=
as its benefits and proponents. Constructor injection quickly swells to unm=
anageable proportions when objects have many dependencies. This becomes par=
ticularly onerous if many of those dependencies are optional dependencies. =
Setter injection better expresses this: If you need a component, set it; if=
 you don't need it, don't set it. Supporting setter injection out of the bo=
x seems like it provides the broadest overall avenue of capability and seem=
s, based on my experience with how people use IoC, like it supports the des=
ires of the greatest percentage of IoC users.
> The important thing, to my mind, is that these setters not be on the inte=
rfaces exposed by the objects. If abstract base classes and other default i=
mplementations expose mutator methods built for initialization, so long as =
the interface they are implementing does not have them, then those mutators=
 are not noise to the end user of the object. In that regard, I agree with =
Kalle: It seems like add/remove semantics should be observed for listeners =
in the interfaces. If the implementation includes setter methods to support=
 that style of injection, then that's hidden from consumers of the object.
> Just my two cents, and probably a bit out of the blue. But I've converted=
 a substantial portion of shiro-core to .NET, so I have a fairly experience=
 with the codebase.
> Bryan Turner
>
>> Date: Wed, 12 May 2010 14:59:36 -0700
>> Subject: Re: r942498 - removing all convenience methods?
>> From: kalle.o.korhonen@gmail.com
>> To: shiro-dev@incubator.apache.org
>>
>> On Wed, May 12, 2010 at 2:43 PM, Les Hazlewood <lhazlewood@apache.org> w=
rote:
>> > Agreed. =C2=A0And after working with all these getters/setters and try=
ing
>> > to figure out when it is safe to initialize things or not, I would
>> > _REALLY_ love to use constructor injection for everything.
>> > Unfortunately, for whatever reason or another, a lot of people seem to
>> > really dislike using it :/
>>
>> They just haven't seen the light yet :)
>>
>> > I guess its because there are scenarios where constructor injection
>> > probably wouldn't be pleasant - think of how many permutations of
>> > config options there are for dependency injection. =C2=A0It seems like=
 that
>> > could get really ugly. =C2=A0I don't know for sure, as I've been using
>> > Spring property injection for some time and only rarely constructor
>> > injection - they allowed me to be lazy in that regard :/
>>
>> Right.. in this specific case a constructor collection and an add
>> operation would be the best choice from Guice/Tapestry 5 perspective
>> but then you'd really need to use either of those IoC containers to
>> implement it properly. And there's no point re-working the internals
>> now - this works and at least, like you said, it's consistent
>> throughout.
>>
>> Kalle
>
> _________________________________________________________________
> Hotmail has tools for the New Busy. Search, chat and e-mail from your inb=
ox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL=
:ON:WL:en-US:WM_HMP:042010_1