You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tim O'Brien <to...@discursive.com> on 2003/06/17 18:31:28 UTC
Re: [math] [Proposal] Deligation of UnivariateImpl to AbstractStoreUnivariate
and refactoring of Univariate Interfaces.
-1, see previous discussion
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
> Proposal:
> The deligation of UnivariateImpl to AbstractStoreUnivariate and
> refactoring of Univariate Interfaces.
>
> Goals:
> (1) I propose that UnivariateImpl should deligate to either a full
> implmentation of StoreUnivariate or it should extend the
> AbstractStoreUnivariate instead of supporting multiple implementations
> of the "Statistical Methods" for StoreUnivariates and UnivariateImpl.
> This way there is only one implementation for a stored statistical
> method approached in AbstractStoreUnivariate. It is the case then that
> when UnivariateImpl has a window and requires storage, that it uses the
> same exact implementation as other storage implementations.
>
> (2) Simplification of the Univariate/StoreUnivariate Interfaces. With
> the above case in mind, there are "methods" that currently do not have
> storageless implementations, but when in a storage based mode,
> UnivariateImpl becomes a storage based implementation, as such those
> methods are now available through the deligation. It is benifical then
> to provide acces to those methods throught the Univariate Interface
> itself. I propose the consolidation of the StoreUnivariate and
> Univariate into one interface (and in the minorboolean cases where a
> UnivariateImpl method is not currently applicable, to just throw a
> runitime exception). Initially, we found storageless implmentations of
> some statistics to be difficult to accomplish. But I feel strongly that
> over time clean solutions will be found, we should not lock ourselves
> out of accomplishing this be restricting the interface.
>
>
> I propose a class heirarchy/naming change to occur based on the
> following class structure
>
> public interface Univarate
> - combines Univariate and StoreUnivariate
> - *defines all Univariate stat and storage access methods*
>
> public abstract class AbstractUnivariate implements Univariate
> - was AbstractStoreUnivariate
> - *implements All Univariate Statistics and storage access*
>
> public class RollingUnivarate extends AbstractUnivariate
> - *storage access and some stats only available when window is set*
>
> public class StoreUnivariateImpl extends AbstractUnivariate
>
> public class ListUnivariateImpl extends AbstractUnivariate
>
> public class BeanListUnivariateImpl extends AbstractUnivariate
>
> Lastly, if the above approach is rejected by the group, then I highly
> recommend that there be separate implementations of the storageless
> "RollingUnivariate" and storage based "RollingStoreUnivariate" to reduce
> the both interface confusion that is currently observable in the
> package between Univariates and StoreUnivariates and the implementation
> complexity observed in the current UnivariateImpl approach.
>
> -Mark Diggory
> Software Developer and Project Manager
> Harvard MIT Data Center
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
--
----------------------
Tim O'Brien
Evanston, IL
(847) 863-7045
tobrien@discursive.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] [Proposal] Deligation of UnivariateImpl to AbstractStoreUnivariate
and refactoring of Univariate Interfaces.
Posted by Tim O'Brien <to...@discursive.com>.
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
> Please be more verbose, are you voting -1 on everything in this message,
> there is more than one recommendation in the proposal.
-1, on Unifying Univariate and StoreUnivariate. I see no need for this,
as there are measures which are impossible to attain without storage.
-1, on throwing RuntimeExceptions in case where methods are not
"available" in a given implementation. If a method is not available for a
storage-less implementation don't make that method available.
This is all a repetition of view expressed in earlier emails. Please roll
back your changes.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] [Proposal] Deligation of UnivariateImpl to AbstractStoreUnivariate
and refactoring of Univariate Interfaces.
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Please be more verbose, are you voting -1 on everything in this message,
there is more than one recommendation in the proposal. Also, I was using
this message to formalize and clarify the changes that I an
recommending, as such I'm trying to make this the point from which more
formal discussion on this topic can extend from.
-Mark
Tim O'Brien wrote:
>-1, see previous discussion
>
>On Tue, 17 Jun 2003, Mark R. Diggory wrote:
>
>
>
>>Proposal:
>>The deligation of UnivariateImpl to AbstractStoreUnivariate and
>>refactoring of Univariate Interfaces.
>>
>>Goals:
>>(1) I propose that UnivariateImpl should deligate to either a full
>>implmentation of StoreUnivariate or it should extend the
>>AbstractStoreUnivariate instead of supporting multiple implementations
>>of the "Statistical Methods" for StoreUnivariates and UnivariateImpl.
>>This way there is only one implementation for a stored statistical
>>method approached in AbstractStoreUnivariate. It is the case then that
>>when UnivariateImpl has a window and requires storage, that it uses the
>>same exact implementation as other storage implementations.
>>
>>(2) Simplification of the Univariate/StoreUnivariate Interfaces. With
>>the above case in mind, there are "methods" that currently do not have
>>storageless implementations, but when in a storage based mode,
>>UnivariateImpl becomes a storage based implementation, as such those
>>methods are now available through the deligation. It is benifical then
>>to provide acces to those methods throught the Univariate Interface
>>itself. I propose the consolidation of the StoreUnivariate and
>>Univariate into one interface (and in the minorboolean cases where a
>>UnivariateImpl method is not currently applicable, to just throw a
>>runitime exception). Initially, we found storageless implmentations of
>>some statistics to be difficult to accomplish. But I feel strongly that
>>over time clean solutions will be found, we should not lock ourselves
>>out of accomplishing this be restricting the interface.
>>
>>
>>I propose a class heirarchy/naming change to occur based on the
>>following class structure
>>
>>public interface Univarate
>> - combines Univariate and StoreUnivariate
>> - *defines all Univariate stat and storage access methods*
>>
>>public abstract class AbstractUnivariate implements Univariate
>> - was AbstractStoreUnivariate
>> - *implements All Univariate Statistics and storage access*
>>
>>public class RollingUnivarate extends AbstractUnivariate
>> - *storage access and some stats only available when window is set*
>>
>>public class StoreUnivariateImpl extends AbstractUnivariate
>>
>>public class ListUnivariateImpl extends AbstractUnivariate
>>
>>public class BeanListUnivariateImpl extends AbstractUnivariate
>>
>>Lastly, if the above approach is rejected by the group, then I highly
>>recommend that there be separate implementations of the storageless
>>"RollingUnivariate" and storage based "RollingStoreUnivariate" to reduce
>>the both interface confusion that is currently observable in the
>>package between Univariates and StoreUnivariates and the implementation
>>complexity observed in the current UnivariateImpl approach.
>>
>>-Mark Diggory
>>Software Developer and Project Manager
>>Harvard MIT Data Center
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org