Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 13 Feb 2012 00:07:03 +0000 (UTC)
From: "Gilles (Commented) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <342501620.30175.1329091623376.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1259661721.35315.1321461112309.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MATH-707) Naming confusion
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Gilles commented on MATH-707:
-----------------------------

Done as of revision 1243370.

Instead of removing {{RealPointValuePair}} and {{VectorialPointValuePair}}, I've just renamed them {{PointValuePair}} and {{PointVectorValuePair}} (according to the convention agreed on here) and made them subclasses of {{Pair}}. This is needed in order to be able to keep the old semantics of "getPoint" and "getValue" which returned copies of the stored data; by using the {{Pair}} directly, we can only return a reference to the "key" and "value". Personally, I think that it shouldn't be a problem in this context (the pair is just used to check convergence, and probably discarded afterwards: the optimizer will instantiates another pair in the next iteration...).
So, proceeding with a semantic change ("getKey" would replace "getPointRef" and "getValue" would replace "getValueRef"; the current "getPoint" and "getValue", returning copies, would disappear)?

                
> Naming confusion
> ----------------
>
>                 Key: MATH-707
>                 URL: https://issues.apache.org/jira/browse/MATH-707
>             Project: Commons Math
>          Issue Type: Task
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Trivial
>              Labels: api-change
>             Fix For: 3.0
>
>
> This issue was raised in [this thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar", "Vectorial", ...), with "Real" and "Scalar" components in names being assumed (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is sometimes included in the name and sometimes not, or used instead of "Scalar").

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira