You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by Michael Allman <ms...@nfcexperts.com> on 2004/02/27 18:47:19 UTC
value getter/setter suggestion
A while back I complained about the use of JavaBean style getters/setters
for getting/setting the value of a mutable xmlObject. For example, in
org.apache.xmlbeans.XmlDate we have
public void setCalendarValue(Calendar c)
public void setDateValue(Date d)
public void setGDateValue(GDate gd)
with the original methods
public void set(Calendar c)
public void set(Date d)
public void set(GDateSpecification gd)
deprecated.
I'd like to suggest that, as a middle ground/compromise alternative to
public void setSomeClassValue(SomeClass someClass)
public SomeClass getSomeClassValue()
we use
public void setValueAsSomeClass(SomeClass someClass)
public SomeClass getValueAsSomeClass()
or
public void setAsSomeClass(SomeClass someClass)
public SomeClass getAsSomeClass()
or
public void setValue(SomeClass someClass)
public SomeClass getValueAsSomeClass()
.
With any of these alternatives XMLBeans maintains compatibility with
JavaBeans tools while telling the alert programmer that "setAs" and
"getAs" style methods on an XmlObject-derivative set and get the value of
the subject mutable object rather than setting and getting any properties
thereof.
Any takers? I'll work on a patch if I hear agreement.
Michael
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: value getter/setter suggestion
Posted by Michael Allman <ms...@nfcexperts.com>.
On Fri, 27 Feb 2004, David Bau wrote:
> Michael, your new suggested names are better than the
> current ones.
>
> Is the proposal to remove the current ones and replace them,
> or to deprecate the current ones without removing them and
> adding the new spellings?
I propose removing the second generation names altogether. They never
appeared in any release. Anyone who uses head code from cvs should know
the risks. While changing the public API is not such a grand idea in
general, in this case we have code which has never seen daylight in either
a source or binary release. In fact, XMLBeans is clearly labeled as
"incubating" on the official website, with all the necessary disclaimers.
Michael
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: value getter/setter suggestion
Posted by Michael Allman <ms...@nfcexperts.com>.
On Fri, 27 Feb 2004, David Bau wrote:
> Michael, your new suggested names are better than the
> current ones.
>
> Is the proposal to remove the current ones and replace them,
> or to deprecate the current ones without removing them and
> adding the new spellings?
I propose removing the second generation names altogether. They never
appeared in any release. Anyone who uses head code from cvs should know
the risks. While changing the public API is not such a grand idea in
general, in this case we have code which has never seen daylight in either
a source or binary release. In fact, XMLBeans is clearly labeled as
"incubating" on the official website, with all the necessary disclaimers.
Michael
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: value getter/setter suggestion
Posted by David Bau <da...@hotmail.com>.
Michael, your new suggested names are better than the
current ones.
Is the proposal to remove the current ones and replace them,
or to deprecate the current ones without removing them and
adding the new spellings?
Seems like a tough tradeoff.
(1) Having 3 equivalent ways seems like it might look a
little crowded and confusing.
(2) If we remove the old names, are we going to have
compatibility concerns?
I'd like to hear if other people here have an opinion.
(1) Would having 3 equivalent methods be confusing?
(2) Would the compatibility issues for removing the old way
cause problems for anybody here?
David
----- Original Message -----
From: "Michael Allman" <ms...@nfcexperts.com>
To: <xm...@xml.apache.org>
Sent: Friday, February 27, 2004 12:47 PM
Subject: [xmlbeans-dev] value getter/setter suggestion
> A while back I complained about the use of JavaBean style
getters/setters
> for getting/setting the value of a mutable xmlObject. For
example, in
> org.apache.xmlbeans.XmlDate we have
>
> public void setCalendarValue(Calendar c)
> public void setDateValue(Date d)
> public void setGDateValue(GDate gd)
>
> with the original methods
>
> public void set(Calendar c)
> public void set(Date d)
> public void set(GDateSpecification gd)
>
> deprecated.
>
> I'd like to suggest that, as a middle ground/compromise
alternative to
>
> public void setSomeClassValue(SomeClass someClass)
> public SomeClass getSomeClassValue()
>
> we use
>
> public void setValueAsSomeClass(SomeClass someClass)
> public SomeClass getValueAsSomeClass()
>
> or
>
> public void setAsSomeClass(SomeClass someClass)
> public SomeClass getAsSomeClass()
>
> or
>
> public void setValue(SomeClass someClass)
> public SomeClass getValueAsSomeClass()
>
> .
>
> With any of these alternatives XMLBeans maintains
compatibility with
> JavaBeans tools while telling the alert programmer that
"setAs" and
> "getAs" style methods on an XmlObject-derivative set and
get the value of
> the subject mutable object rather than setting and getting
any properties
> thereof.
>
> Any takers? I'll work on a patch if I hear agreement.
>
> Michael
>
> - --------------------------------------------------------
-------------
> To unsubscribe, e-mail:
xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail:
xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL:
http://xml.apache.org/xmlbeans/
>
>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: value getter/setter suggestion
Posted by David Bau <da...@hotmail.com>.
Michael, your new suggested names are better than the
current ones.
Is the proposal to remove the current ones and replace them,
or to deprecate the current ones without removing them and
adding the new spellings?
Seems like a tough tradeoff.
(1) Having 3 equivalent ways seems like it might look a
little crowded and confusing.
(2) If we remove the old names, are we going to have
compatibility concerns?
I'd like to hear if other people here have an opinion.
(1) Would having 3 equivalent methods be confusing?
(2) Would the compatibility issues for removing the old way
cause problems for anybody here?
David
----- Original Message -----
From: "Michael Allman" <ms...@nfcexperts.com>
To: <xm...@xml.apache.org>
Sent: Friday, February 27, 2004 12:47 PM
Subject: [xmlbeans-dev] value getter/setter suggestion
> A while back I complained about the use of JavaBean style
getters/setters
> for getting/setting the value of a mutable xmlObject. For
example, in
> org.apache.xmlbeans.XmlDate we have
>
> public void setCalendarValue(Calendar c)
> public void setDateValue(Date d)
> public void setGDateValue(GDate gd)
>
> with the original methods
>
> public void set(Calendar c)
> public void set(Date d)
> public void set(GDateSpecification gd)
>
> deprecated.
>
> I'd like to suggest that, as a middle ground/compromise
alternative to
>
> public void setSomeClassValue(SomeClass someClass)
> public SomeClass getSomeClassValue()
>
> we use
>
> public void setValueAsSomeClass(SomeClass someClass)
> public SomeClass getValueAsSomeClass()
>
> or
>
> public void setAsSomeClass(SomeClass someClass)
> public SomeClass getAsSomeClass()
>
> or
>
> public void setValue(SomeClass someClass)
> public SomeClass getValueAsSomeClass()
>
> .
>
> With any of these alternatives XMLBeans maintains
compatibility with
> JavaBeans tools while telling the alert programmer that
"setAs" and
> "getAs" style methods on an XmlObject-derivative set and
get the value of
> the subject mutable object rather than setting and getting
any properties
> thereof.
>
> Any takers? I'll work on a patch if I hear agreement.
>
> Michael
>
> - --------------------------------------------------------
-------------
> To unsubscribe, e-mail:
xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail:
xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL:
http://xml.apache.org/xmlbeans/
>
>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/