Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

>Note that the Pico guys have already stated that they will *not* support
Type 2 IoC any time soon but just their flavour of Type 3.

A couple of weeks ago, I tried to persuade Paul to support Type 3, but to no
avail.

Btw, Paul and I got on great: we agree on a lot of stuff, such as the
importance of IoC, TDD, lightweight architectures etc.

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Monday, November 10, 2003 4:11 PM
Subject: Re: [Springframework-developer] Type 3 IoC support


Due to popular demand ;-), I've just added a constructor detection algorithm
that replaces the former single-constructor requirement. It works similar to
Pico's constructor resolution: It starts with the "greediest" constructor,
i.e. the one with the most arguments, and then falls back to the next one in
the greediness order if it can't resolve all dependencies. If there are
multiple constructors with the same number of arguments, all of them are
tried; the first one that can be satisfied will be used.

Of course, all "constructor-arg" hints will be applied in any case;
autowire="constructor" will just resolve all remaining arguments. A few
sanity checks are performed, like only resolving a constructor that has at
least as many arguments as there are "constructor-arg" tags.

This should be sufficiently powerful to be able to address *any*
constructor. For example, if there are constructors (DataSource,TestBean)
and (TestBean,DataSource), autowiring or generic "constructor-arg" tags with
a DataSource and a TestBean will use an undetermined one of the two
(generally, the first one according to the order of Class.getConstructors,
which can vary from JVM to JVM). If you need a specific one, use
"constructor-arg" with corresponding "index" attributes.

If multiple constructors with the same number and position of arguments
match, like (DataSource,TestBean) and (DataSource,Object), a type difference
weight algorithm will kick in. It will determine a weight for the difference
between the argument types and the actual arguments, prefering more exact
matches - (DataSource,TestBean) in case of DataSource and TestBean args, in
the above case.

BTW, Rob, Pico still advocates the single constructor paradigm. Their
introduction (http://www.picocontainer.org/introduction.html) still states
that Pico components need to have one single constructor, while their FAQ
talk about resolving an appropriate constructor
(http://www.picocontainer.org/faq.html#many-constructors) - so much for
documentation consistency.

I consider our Type 3 IoC support now more capable than Pico's: We also
support arrays, lists, and maps of components or parameters going into
constructor arguments, just like we do with bean properties. Effectively,
bean-style Type 2 IoC vs constructor-style Type 3 IoC is now the application
developer's choice when using a Spring bean factory. Note that the Pico guys
have already stated that they will *not* support Type 2 IoC any time soon
but just their flavour of Type 3.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Butler
Sent: Sunday, November 09, 2003 11:47 PM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Type 3 IoC
support - Email found in subject


I would agree this is very good stuff!  This is especially useful if you
want to use a third party api but they do not conform to javabean style
no-arg contructors.  However by limiting the implementation to only support
classes that have a single constructor you are all but defeating its
usefulness.

The only reason you would be forced to use / need this kind of a feature is
if you don't have access to the code to implement a no-arg constructor.  For
that same reason, you cannot modify the code to only have 1 constructor. I
would wager that most classes that do provide a constructor which takes args
also supply variations that take more / less args.  So if multiple
constructors are not supported, it's probably not going to be very useful.

Spring is already amazing, and you guys just keep making it better.  Good
work!

Later
Rob
> >
> >The only limitation is that constructor-wired components are just allowed
to have one single constructor. This is also what Pico recommends, although
they have some heuristic kind of constructor choice in case of multiple
constructors now. I guess we can limit this to one single constructor for
the time being. Of course, standard beans defined without
autowire="constructor" or "constructor-arg" tags can still have any number
of constructors, the only requirement being that they must provide a no-arg
constructor.
> >
> >
> One way you could do it (which you probably thought of) is by allowing
> the deployer to specify, in the case of the indexed variant, an optional
> 'type' attribute which specifies the real type (in the receiving object)
> of that constructor argument. This would allow the appropriate
> constructor to be picked without any ambiguity. I don't know if this is
> worth doing or not, but on the other hand, if you are going to support
> constructors at all, it's somewhat arbitrary to stop at 1 if you can
> figure out a relatively simple (albeit wordy) way to support the
> multiple case.
>
> Even if that is not done, maybe it is worth it supporting the special
> case of classes which have a no-arg constructor, and one other
> constructor with one or more args. That's also a pretty common case, and
> easy to support.
>
> Regards,
> Colin
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer