[ 
https://issues.apache.org/jira/browse/MATH-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000601#comment-13000601
 ] 

Gilles commented on MATH-535:
-----------------------------

In the end, I don't think that these methods are useful. Within the current 
code, all they would do is hide a constructor call. In the case of 
"createParametric()" the returned object would not be very interesting: e.g. a 
caller that would treat it as a "ParametricUnivariateRealFunction" would not 
know how many parameters are needed to call "value(double x, double[] param)".
So, unless someone sees a real usefulness, I'm going to close this issue.


> Closing the loop in function objects
> ------------------------------------
>
>                 Key: MATH-535
>                 URL: https://issues.apache.org/jira/browse/MATH-535
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Priority: Minor
>              Labels: api-change
>             Fix For: 3.0
>
>
> Some function classes (in package "analysis.function") now contains a 
> "Parametric" inner class that provides a parametric version of the function 
> represented by the enclosing class.
> # We could enhance the "UnivariateRealFunction" interface to contain:
> {noformat}
>   public ParametricUnivariateRealFunction createParametricFunction();
> {noformat}
> which, e.g. for the "Gaussian" concrete class, would translate to:
> {noformat}
>   public Gaussian.Parametric createParametricFunction() {
>     return new Gaussian.Parametric();
>   }
> {noformat}
> # We could enhance the "ParametricUnivariateRealFunction" interface to 
> contain:
> {noformat}
>   public UnivariateRealFunction createFunction(double[] param);
> {noformat}
> which, in "Gaussian.Parametric", would translate to:
> {noformat}
>   public Gaussian createFunction(double[] param) {
>     validateParameters(param);
>     return new Gaussian(param[0], param[1], param[2]);
>   }
> {noformat}
> In both cases, it would allow programming against interfaces.
> For the first case, not all current implementations of 
> "UnivariateRealFunction" provide a "Parametric" version (and for most there 
> are no parameters). So either we create a new 
> "AbstractUnivariateRealFunction" that provides a default implementation of 
> "createParametricFunction" (throwing an exception) and make all current 
> function classes extends this one, or we create a new interface (something 
> like "ParametricFactory") that declares the new "createParametricFunction()" 
> and add the "implements ParametricFactory" clause to any class that provides 
> a parametric version.
> I think that the latter is the cleanest. Or is there still another 
> possibility?

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to