Daniel,
sound a good proposal. This raises all sorts of questions in my mind,
and I'm not an expert in this area. Have you any detailed thoughts about
how this might work out? Here's my first, possibly slightly jumbled
reactions ...
I think this would be a trip hazard if it were only done on the static API,
so I think it's a spec issue. It would be a severe limitation for code to
have to know when it was dealing with dynamic or static data objects, and
graphs of mixed objects would present a problem for generic code. We could
add an SDOUtil method that produces the Tuscany concept of a hashCode for
dynamic or static data objects.
Would you imagine that the generator creates a bespoke equality method per
class, or defer to the EqualityHelper?
Currently we rely on the EMF EqualityHelper to underpin Tuscany's SDO
EqualityHelper behind the scenes in order to determine equality using EMF
dynamic APIs. The EMF dynamic API is used whether or not the data graphs
are built with dynamic or static data objects. I can't see an EMF override
of hashCode() anywhere in the EMF EObject hierarchy that would allow us to
readily preserve the invariant that ...
a.equals(b) => a.hashCode() == b.hashCode()
If we were to create a hashCode() algorithm of our own to match the logic of
the EMF EqualityHelper I guess there's scope for some fragility, although I
imagine that the EMF EqualityHelper is a pretty stable thing now.
--
Kelvin.
On 11/05/07, Daniel Peter <[EMAIL PROTECTED]> wrote:
Hi all,
I see that the EqualityHelper provides the logic for
determining the equality of SDOs.
Is there a way to make the generator produce 'equals'
and 'hashcode' methods in the generated SDO classes?
Thanks, Daniel.
__________________________________ Kennt man wirklich jeden über 3
Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
