On 9/2/07, Luc Maisonobe <[EMAIL PROTECTED]> wrote: > On 2007-05-15, Phil Steitz wrote: > > > I agree. So, probably best is to deprecate the current abstract > > factories and move to single concrete factories with impl setters for
> > IOC support. The concrete factories exist already, so it may just be > > a matter of deprecation and possibly renaming some things. Here > > again, we could deprecate in 1.2, remove in 2.0. Lets step back and > > reexamine the overall setup and introduce a better approach. All ideas > > / suggestions welcome. Consistency is important, though, so whatever > > we decide on, lets be consistent in distributions, solvers, etc. > > I am working on a new UnknownDistributionChiSquareTest interface > concerning issue https://issues.apache.org/jira/browse/MATH-160, and I > have to find the proper way to create instances. We talk about factories > and deprecation, and I think there are still issues. > > I think deprecating the abstract factories and using only the concrete > implementations would not be wise, it seems strange to have a > non-deprecated class extend a deprecated one. We should better remove > the "abstract" qualifier and simply push the concrete code up. Then we > can add the setters in these single factories for IOC concerns. The > current XxxFactoryImpl classes would then become empty and would be > deprecated. Does this seem sensible to everybody ? > This is an interesting idea, but I am not sure we need to continue to support the factories. The approach that we took in the distributions package was just to deprecate the factories, leaving it to the user code (or IOC framework) to create instances. If you look at our internal use of the distributions, this seems to work OK. ChiSquareTestImpl, for example, now exposes a setter for the ChiSquareDistribution that it uses. I guess what it comes down to is how often will users want to configure or use multiple classes sourced from the same factory, how many users use the to-be-deprecated factories now, and how bad is it to force users to directly instantiate the Impl classes. My intuition is not that none of these are that bad, so I guess I remain in favor of the current "get out of the factory business" approach. On the other hand, if a) there are no backward compatibility problems with the approach that you describe and b) we do it uniformly (so go back and change distributions), then I am OK with it. Interested in others' views on this as well. Phil > Luc > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
