xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allman, Michael" <Michael.All...@ssa.gov>
Subject RE: deprecated methods
Date Wed, 14 Jan 2004 15:25:02 GMT
Hi David,

Thanks for your excellent response.  I had a feeling you'd know what was up.

After reading your arguments for getters/setters I'm still not convinced.
It sounds like the decision hinged around JavaBean tool compliance.  I don't
know how that applies since XmlInt, for example, is not a JavaBean.

Let me present my case in favor of "the old way".

As we all know, one of the chief purposes of JavaBeans (perhaps their main
purpose) is to bind properties in a componentized way.  JavaBeans have a
standard means of exposing their properties via getter/setter methods.

Now consider XmlInt.  I've already argued that it's not a JavaBean because
it's an interface (plus, it doesn't even derive from Serializable).  If we
treat it like a JavaBean with getIntValue() and setIntValue(), doesn't that
mean (ala the JavaBeans "contract") that XmlInt has a property called
intValue (or IntValue)?  Of course it doesn't.  It can't --- it's an
interface.  Even if we consider a concrete class implementing XmlInt, the
"intValue property" argument doesn't hold water.  If XmlInt has a property
called intValue, then, by extension, it must have *separate* properties
called longValue, bigIntegerValue, bigDecimalValue, and stringValue.  This,
of course, is not the case.  A JavaBean tool which introspects an object
whose class implements XmlInt will find all of these properties and naively
present them as distinct JavaBeans properties.  A naive programmer might
then be led to believe that they can fiddle with these properties
independently, because that's the way JavaBeans work.  But even if they
weren't naive, surely this would raise eyebrows?

The "old way", namely intValue() and set(), makes sense to me because really
we're converting to and from Java ints and XMLBeans XmlInts.  XmlInt doesn't
have a "property" called intValue.  It's an XML int, and it naturally
corresponds in a natural mapping into Java-space to a Java int.  In fact, to
quote the JavaDoc for XmlInt, "Naturally, convertible to a Java int."
Doesn't that say it all?

I hope I've presented a convincing argument.

Thanks for listening.


> -----Original Message-----
> From: David Bau [mailto:david.bau@bea.com] 
> Sent: Tuesday, January 13, 2004 5:57 PM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: deprecated methods
> Hi Michael,
> The reason that you can't find the debate on the lists was 
> that the @deprecation happened before the code was 
> contributed to Apache!  There was a pre-Apache debate...  I 
> don't remember all the details, but the reasoning went 
> something like this.
> (1) Generated XMLBeans look just like JavaBeans, by design.
> (2) The various JavaBeans tools out there inspect bean-like 
> objects by looking at all the "getX"/"setX" methods, and 
> showing the values.  For example, a visual debugger might 
> know how to display or edit a JavaBean with nicely named 
> getters and setters.  A JSP/struts-like binding tool might 
> know how to work with setX and getX.
> (3) But the intValue() and set() methods don't conform to 
> that naming convention, and so are invisible to those kinds 
> of tools.  The intValue is arguably the most interesting 
> thing inside any XmlInt (or any complex type that might 
> derive from XmlInt), so this is a major outage for those users.
> (4) One possible name to use would be to say setValue() and 
> getValue().  But this has two disadvantages: (i) "value" is a 
> common enough XML element name that it's just begging for a 
> conflict, where "intValue" is not. (ii) any class that needs 
> to implement two different getValue() methods of different 
> types would run into a conflict in Java (e.g., in schema, an 
> int is also a long, integer, and a decimal).
> (5) So it was settled that getIntValue() and setIntValue() 
> would be the names to use.
> We can certainly debate whether they should be undeprecated 
> and changed back (the original names from before were mine 
> and I liked them too), but I think the the argument for the 
> change was strong.
> David
> ----- Original Message ----- 
> From: "Allman, Michael" <Michael.Allman@ssa.gov>
> To: <xmlbeans-dev@xml.apache.org>
> Sent: Tuesday, January 13, 2004 11:34 AM
> Subject: [xmlbeans-dev] deprecated methods
> > Can someone explain why methods such as XmlInt.intValue() and 
> > XmlInt.set() have been deprecated in favor of JavaBean-like getters 
> > and setters?  I
> can't
> > find any background on this change in the mailing list 
> archive or CVS. 
> > Similar changes have been made to the XmlInteger, 
> XmlString, XmlFloat 
> > and other interfaces.  I'm sure there must be some good reason I'm
> overlooking.
> >
> > I like the way it was before.  Can we debate these changes?  Did I 
> > miss
> the
> > debate?
> >
> > 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/

View raw message