|
Home > Archive > Apache JDO Project > November 2005 > Issue 146: TCK : ResultClassRequirements.testNegative
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Issue 146: TCK : ResultClassRequirements.testNegative
|
|
| Craig L Russell 2005-11-23, 5:45 pm |
| Hi,
I've reviewed the spec and I'm inclined to agree with Andy about the
intent, and with both Andy and Michael about the exact wording of the
specification, which does appear to disallow the negative test case
as written. Although there is some ambiguity that I think we should
clean up regardless.
It seems that the following queries have the same semantics but due
to the way the spec is written, have very different behavior. The
first query disallows the use of the (long, String) constructor
whereas the second query could use set or put methods if there were
no corresponding constructor (even though a constructor appears to be
called for by the use of the "new" keyword). As an aside, the first
query seems to be more readable...
SELECT personid, lastname
INTO org.apache.jdo.tck.query.result.classes.LongString
FROM org.apache.jdo.tck.pc.company.FullTimeEmployee
SELECT new org.apache.jdo.tck.query.result.classes.LongString
(personid, lastname)
FROM org.apache.jdo.tck.pc.company.FullTimeEmployee
I remember having the discussion about constructors when we talked
about the constructor specification in the setResult versus the
constructor in the setResultClass. I do not remember why we chose to
restrict the case discussed in the bug report. It could simply be my
bad transcription of the discussion.
To remedy this, I propose changing the spec to move the
setResultClass phrase. This change implements Andy's suggestion
below, making the above queries semantically and behaviorally
equivalent.
<spec 14.6.12>
A constructor of a result class specified in the setResult method
will be used if the results specification matches the parameters of
the constructor by position and type. If more than one constructor
satisfies the requirements, the JDO implementation chooses one of
them. If no constructor satisfies the results requirements, or if the
result class is specified via the setResultClass method, the
following requirements apply:
</spec 14.6.12>
<proposed 14.6.12>
A constructor of a result class specified in the constructor
expression of the setResult method or in the setResultClass method
will be used if the results specification matches the parameters of
the constructor by position and type. If more than one constructor
satisfies the requirements, the JDO implementation chooses one of
them. If no constructor satisfies the results requirements, the
following requirements apply:
</proposed 14.6.12>
On Nov 23, 2005, at 10:45 AM, Andy Jefferson wrote:
> Hi Michael,
>
>
>
> OK, your test is following the "rules" in the latest spec to the
> letter :-).
> I prefer to look at it from a user viewpoint. "setResultClass" is
> the place
> where the vast majority of people will specify the result class.
> The spec
> seemingly isn't allowing a user to provide a result class with the
> correct
> constructor parameters and use that to construct the object. This is a
> limitation that I see no obvious reason for. Is there a reason ?
>
> IMHO, the sequence should be
> 1. Use a constructor with the parameter positions/types.
>
> or
>
> 2. Use a default constructor
> 2a. public fields matching name and type
> 2b. public set method matching name and type
> 2c. public put(Object, Object) method
>
>
> --
> Andy
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
| |
| Michael Bouschen 2005-11-23, 5:45 pm |
| Hi Craig,
+1 to change the spec as proposed.
Regards Michael
> Hi,
>
> I've reviewed the spec and I'm inclined to agree with Andy about the
> intent, and with both Andy and Michael about the exact wording of the
> specification, which does appear to disallow the negative test case as
> written. Although there is some ambiguity that I think we should clean
> up regardless.
>
> It seems that the following queries have the same semantics but due to
> the way the spec is written, have very different behavior. The first
> query disallows the use of the (long, String) constructor whereas the
> second query could use set or put methods if there were no
> corresponding constructor (even though a constructor appears to be
> called for by the use of the "new" keyword). As an aside, the first
> query seems to be more readable...
>
> SELECT personid, lastname
> INTO org.apache.jdo.tck.query.result.classes.LongString
> FROM org.apache.jdo.tck.pc.company.FullTimeEmployee
>
> SELECT
> new org.apache.jdo.tck.query.result.classes.LongString (personid,
> lastname)
> FROM org.apache.jdo.tck.pc.company.FullTimeEmployee
>
> I remember having the discussion about constructors when we talked
> about the constructor specification in the setResult versus the
> constructor in the setResultClass. I do not remember why we chose to
> restrict the case discussed in the bug report. It could simply be my
> bad transcription of the discussion.
>
> To remedy this, I propose changing the spec to move the setResultClass
> phrase. This change implements Andy's suggestion below, making the
> above queries semantically and behaviorally equivalent.
>
> <spec 14.6.12>
> A constructor of a result class specified in the setResult method will
> be used if the results specification matches the parameters of the
> constructor by position and type. If more than one constructor
> satisfies the requirements, the JDO implementation chooses one of
> them. If no constructor satisfies the results requirements, or if the
> result class is specified via the setResultClass method, the following
> requirements apply:
> </spec 14.6.12>
>
> <proposed 14.6.12>
> A constructor of a result class specified in the constructor
> expression of the setResult method or in the setResultClass method
> will be used if the results specification matches the parameters of
> the constructor by position and type. If more than one constructor
> satisfies the requirements, the JDO implementation chooses one of
> them. If no constructor satisfies the results requirements, the
> following requirements apply:
> </proposed 14.6.12>
>
> On Nov 23, 2005, at 10:45 AM, Andy Jefferson wrote:
>
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
|
|
|
|
|