shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: r942498 - removing all convenience methods?
Date Thu, 13 May 2010 00:18:59 GMT
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 :)


On Wed, May 12, 2010 at 4:29 PM, Bryan Turner <> wrote:
> I'd like to jump in on this and say that I think both approaches have value. There's
little reason, in my opinion, why both can't be done. add/remove methods do not necessarily
preclude get/set methods; I think both should be in the code for these sorts of framework
> 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 has its benefits and proponents. Constructor injection quickly
swells to unmanageable proportions when objects have many dependencies. This becomes particularly
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 box seems like it provides the broadest overall avenue of capability
and seems, based on my experience with how people use IoC, like it supports the desires of
the greatest percentage of IoC users.
> The important thing, to my mind, is that these setters not be on the interfaces exposed
by the objects. If abstract base classes and other default implementations 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:
>> To:
>> On Wed, May 12, 2010 at 2:43 PM, Les Hazlewood <> wrote:
>> > Agreed.  And after working with all these getters/setters and trying
>> > 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.  It seems like that
>> > could get really ugly.  I 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 inbox.

View raw message