DO NOT REPLY [Bug 29068] - [math] Improve performance, flexibility of discovery impl

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29068>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29068

[math] Improve performance, flexibility of discovery impl





------- Additional Comments From mdiggory@latte.harvard.edu  2004-06-06 00:37 -------
My major concern is that there are multiple usecases here, even in your code
example:

DistributionFactory factory = DistributionFactory.newInstance();

vs.

DistributionFactory factory = DistributionFactory.getInstance();

Here, the first case may construct a DistributionFactory where some internal
state/environment is maintained which makes it different than another
DistributionFactory. You can see this sort of case in examples such as SAX and
JAXP where the Factory instance is configurable and produces objects with
different states. 

In another example, with DescriptiveStatistics.newInstance() we have an issue
where the instantiated factory is also the object, it has unique state we want
to maintain multiple instances of the object. Having these methods be
getInstance instead of newInstance would be very limiting.

Right now DistributionFactory has no state that would make it anymore unique
than any other distribution factory. Which makes me think your suggested change
would be fine. But, maybe we should evaluate if we think a Factory is going to
have greater capability or configurability in the future and try not to shoot
ourselves in the foot by limiting it to a singleton status.

Finally, I wonder, if your going to reuse the object as a singleton, do
synchronous issues arise with concurrent access via the methods in the factory?

I feel we should do a review and identify the Factories we would approach this
with and bring up discussion on each. Maybe we should try to identify the types
of factories we want to maintain.  There should be some analysis applied to
determine if the Factory instance is configurable. If it is, then "newInstance"
should be maintained. If not, the getInstance could be appropriate in cases
where reuse can occur.


Singleton Factory:
factory backed by a singleton instances of itself

Configurable Factory:
factory which can produce uniquely configured instances of itself

???

-Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org