Re: [sca-j] ISSUE-117: Clarify the name implied by setter methodfor property and reference names

[Simon Nash <oasis@cjnash.com>]

SCA should use the same pattern that JavaBeans uses for inferring
property names.  This is well established and familiar to Java
programmers.  The following sections from the JavaBeans specification
define the relevant details:

  8.3 Design Patterns for Properties
  8.3.1 Simple properties
  By default, we use design patterns to locate properties by looking for methods of the form:
  public <PropertyType> get<PropertyName>();
  public void set<PropertyName>(<PropertyType> a);
  If we discover a matching pair of “get<PropertyName>” and “set<PropertyName>” methods
  that take and return the same type, then we regard these methods as defining a read-write property
  whose name will be “<propertyName>”. We will use the “get<PropertyName>” method
  to get the property value and the “set<PropertyName>” method to set the property value. The
  pair of methods may be located either in the same class or one may be in a base class and the
  other may be in a derived class.
  If we find only one of these methods, then we regard it as defining either a read-only or a writeonly
  property called “<propertyName>”
  By default we assume that properties are neither bound nor constrained (see Section 7).
  So a simple read-write property “foo” might be represented by a pair of methods:
  public Wombat getFoo();
  public void setFoo(Wombat w);

  8.3.2 Boolean properties
  In addition, for boolean properties, we allow a getter method to match the pattern:
  public boolean is<PropertyName>();
  This “is<PropertyName>” method may be provided instead of a “get<PropertyName>” method,
  or it may be provided in addition to a “get<PropertyName>” method.
  In either case, if the “is<PropertyName>” method is present for a boolean property then we will
  use the “is<PropertyName>” method to read the property value.
  An example boolean property might be:
  public boolean isMarsupial();
  public void setMarsupial(boolean m);

  8.3.3 Indexed properties
  If we find a property whose type is an array “<PropertyElement>[]”, then we also look for
  methods of the form:
  public <PropertyElement> get<PropertyName>(int a);
  public void set<PropertyName>(int a, <PropertyElement> b);
  If we find either kind of pattern then we assume that “<propertyName>” is an indexed property
  and that these methods can be used to read and/or write an indexed value.
  Thus an indexed property “foo” might be represented by four accessor methods:
  JavaBeans Introspection
  Sun Microsystems 56 10/12/97
  public Bah[] getFoo();
  public void setFoo(Bah a[]);
  public Bah getFoo(int a);
  public void setFoo(int a, Bah b);

  8.8 Capitalization of inferred names.
  When we use design patterns to infer a property or event name, we need to decide what rules
  to follow for capitalizing the inferred name. If we extract the name from the middle of a normal
  mixedCase style Java name then the name will, by default, begin with a capital letter.
  Java programmers are accustomed to having normal identifiers start with lower case letters.
  Vigorous reviewer input has convinced us that we should follow this same conventional rule
  for property and event names.
  JavaBeans Introspection
  Sun Microsystems 58 10/12/97
  Thus when we extract a property or event name from the middle of an existing Java name, we
  normally convert the first character to lower case. However to support the occasional use of all
  upper-case names, we check if the first two characters of the name are both upper case and if
  so leave it alone. So for example,
  “FooBah” becomes “fooBah”
  “Z” becomes “z”
  “URL” becomes “URL”
  We provide a method Introspector.decapitalize which implements this conversion rule.

So the rule for SCA should be to remove the "set" prefix from the
method name and then apply java.beans.Introspector.decapitalize()
to the result of doing this.  For the examples given in the JIRA,
this produces:
  setPrefix --> prefix
  setprefix --> prefix
  setID     --> ID

   Simon

David Booz wrote:
> http://www.osoa.org/jira/browse/JAVA-117
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> Inactive hide details for C Vamsi ---12/12/2008 09:02:53 AM---TARGET: 
> sca-javaci-draft-20070926.doc sca-javacaa-1.1-spec-cd01-rC Vamsi 
> ---12/12/2008 09:02:53 AM---TARGET: sca-javaci-draft-20070926.doc 
> sca-javacaa-1.1-spec-cd01-rev1.pdf
> 
> 
> From:	
> C Vamsi <vamsic007@in.ibm.com>
> 
> To:	
> sca-j@lists.oasis-open.org
> 
> Date:	
> 12/12/2008 09:02 AM
> 
> Subject:	
> [sca-j] NEW ISSUE: Clarify the name implied by setter method for 
> property and reference names
> 
> ------------------------------------------------------------------------
> 
> 
> 
> TARGET: sca-javaci-draft-20070926.doc
> sca-javacaa-1.1-spec-cd01-rev1.pdf
> 
> DESCRIPTION:
> @Property and @Reference annotations without the name attribute applied on
> setter methods require the property/reference name to be computed from the
> method name.  In CAA and CI specs we mention "... name of the field or
> setter".  What happens in the following case?
> 
> public class WeirdHello {
> 
>    @Property
>    public void setPrefix(String prefix) {
>    ...
>    }
> 
>    @Property
>    public void setprefix(String prefix) {
>    ...
>   }
> 
>    @Property
>    public void setID(String id) {
>    ...
>   }
>   ...
> }
> 
> There is nothing syntactically wrong with this class.  What will be the
> propery names in this case?  Will setID() method result in a property with
> name ID or iD ?  Is it an error?  It is not clear and we need to make it
> clear.
> 
> PROPOSAL: Clarify that the name implied by the setter method is the name
> obtained by removing "set" from the method name.  For e.g. setID() will
> result in "ID", setid() will result in "id" and setPrefix() will result in
> "Prefix" not "prefix".
> 
> ++Vamsi
> Apache Tuscany Committer  http://tuscany.apache.org
> Apache Geronimo Committer and Member of PMC  http://geronimo.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
>