>But equals() is a method on Object, so clients could use it anyway >even if we don't override it. If we don't override it, clients will >get misleading results because equals() called against two different >(different IDs) but equivalent Woden objects will return false instead >of true. If we really want to disallow clients calling equals() then >we should implement it as always throwing UnsupportOperationException >to enforce Woden clients into *not* using it.
For me the issue here is just a matter of setting expectations. If clients don't expect meaningful results from equals that's fine. If there do expect meaningful results because the Woden DOM implementation provides them then we need to be clear about what clients can expect from other implementations. (We can just state that it is up to implementations to define how they implement equals.) I don't think we want to disallow clients from calling equals. And again, I think your proposal can be useful to clients. >Is there an issue with an EMF based impl of Woden not being able to >implement the equals() method? If there's not then I think we should >implement equals(). I don't know of any specific issue. However, one of the issues that came from the Eclipse (EMF and WTP) camp was that the API was too complex. I don't know that this will add complexity. I just want us all to keep complexity in mind as we propose changes as complexity is an issue that has already been raised. Lawrence "Jeremy Hughes" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/23/2007 05:22 AM Please respond to [email protected] To [email protected] cc Subject Re: Woden API Review wiki page On 22/11/2007, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > >I'm not proposing adding anything to the API > > My concern is in adding complexity of the Woden API for other Woden > implementations (say, an EMF based impl), which doesn't necessarily > involve adding complexity to the interfaces. The functionality of the > equals method really is part of the API as it defines an expected function > from the method and other implementations will have to implement the > method in a manner that produces the expected results in order to avoid > breaking clients who use equals. But equals() is a method on Object, so clients could use it anyway even if we don't override it. If we don't override it, clients will get misleading results because equals() called against two different (different IDs) but equivalent Woden objects will return false instead of true. If we really want to disallow clients calling equals() then we should implement it as always throwing UnsupportOperationException to enforce Woden clients into *not* using it. Is there an issue with an EMF based impl of Woden not being able to implement the equals() method? If there's not then I think we should implement equals(). > > >I guess the key question is: where is the requirement for object > >equivalence? Do our users need to determine equality of two WSDL > >components? Do they need to determine equality of two WSDL XML Infoset > >trees. I think there's a good chance they will. > > I think you're right about this although I don't know the specific > comparison requirements. Any idea if Axis2 relies in anyway on equivalence > tests? A very good question. I guess they don't currently. > Lawrence > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 11/22/2007 05:31 PM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Re: Woden API Review wiki page > > > > > > > Hi Lawrence, > > On 22/11/2007, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > > Jeremy, > > > > I'm worried that creating separate impl classes for the component and > > element models will add more complexity to Woden. We've already had > > requests to reduce the complexity of the Woden model. > > What are you counting as the model here? Is it the impl classes or the > API? I'm not proposing adding anything to the API - except removing > the boolean equals(WSDLComponent) method on WSDLComponent, and for us > to implement equals(Object) in our *Impl classes. So conceptually > Woden remains the same. > > Agreed, from an implementation point of view there would be some > additional complexity. But we don't get the 'equals' functionality for > free. At the moment the equals method doesn't work for our classes. > And while we're there we might want to implement hashCode() too so our > *Impl objects can be put into HashMaps etc efficiently. > > If we merge the two APIs then we might still need a way of comparing > the object representation of WSDL from an XML Infoset point of view > and also from the component model point of view. So we might still > need this capability but we'd need to implement it in a different way > to equals(). Perhaps componentEquals() and xmlEquals() - but that > feels really incongruous to me. > > I guess the key question is: where is the requirement for object > equivalence? Do our users need to determine equality of two WSDL > components? Do they need to determine equality of two WSDL XML Infoset > trees. I think there's a good chance they will. > > > > > Lawrence > > > > > > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 11/22/2007 12:07 PM > > Please respond to > > [email protected] > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: Woden API Review wiki page > > > > > > > > > > > > > > One idea I have is to think in terms of the MVC pattern. The current > > *Impl classes are the model, the *Element interfaces include > > controller methods (add* etc). We have two views - the component view > > and the element (XML infoset) view. > > > > Right now the *Impl classes directly implement the component and > > element java interfaces. So there is only one equals() implementation > > and that needs to cover both component and element views. > > > > If we separate the *Impl classes from those interfaces, by having a > > lightweight 'component view' implementation and an 'element view' > > implementation, then we can have a separate implementation of equals() > > for each. The other methods will simple delegate straight into the > > existing *Impl classes. > > > > This will be easier to talk about with some code to look at so I'll > > put together a sample of what I mean. > > > > Cheers, > > Jeremy > > > > On 22/11/2007, John Kaputin <[EMAIL PROTECTED]> wrote: > > > Merging the Component and Element APIs will not solve the problem of > > > implementing equals(Object) to determine logical equality. The object > > > model will still contain Component model and Infoset data and equality > > > between components does not necessarily mean their infosets are > > > equivalent. Some component properties are derived by evaluating the > > > attributes present in the infoset and applying certain rules. It's > > > possible to have equivalent Component models created from different > XML > > > infosets. > > > > > > We could decide that equals(Object) applies to WSDL Component model > > > equivalence only, but that does mean we could end up with two objects > > with > > > different infoset data being considered equal. We won't be able to use > > > equals(Object) for checking equivalence in the WSDL infoset model. > Maybe > > > that doesn't matter. Maybe it's enough just to use the Component > > > equivalence defined in the spec when comparing Woden WSDL objects via > > > equals(Object). > > > > > > regards, > > > John Kaputin > > > > > > > > > [EMAIL PROTECTED] wrote on 21/11/2007 17:13:18: > > > > > > > One issue is the equals() method. As things stand there is an > > > > equals(WSDLComponent) method on WSDLComponent interface and > > > > implemented trivially on WSDLComponentImpl. Unfortunately if you > > > > compare two DescriptionElement objects the equals(Object) method is > > > > called which returns false. There is a fundamental problem with > having > > > > a single implementation class implementing the WSDLComponent and > > > > WSDLElement interfaces. > > > > > > > > If I want to compare two DescriptionElement instances with each > other > > > > then equals(Object) needs to be implemented (by DescriptionImpl) and > > > > that implementation needs to do the comparison at the XML infoset > > > > level. > > > > > > > > If I want to compare two Description instances (ie at the component > > > > model level) then equals(Object) needs to be implemented (by > > > > DescriptionImpl) and that implementation needs to do the comparison > at > > > > the Component model level. > > > > > > > > There's a conflict here ... the equals() method doesn't know which > one > > > to do! > > > > > > > > So ... firstly, is object comparison something we wish to allow our > > > > users to do. I think it would be useful and equals() is a > fundamental > > > > part of a well formed API. > > > > > > > > Not quite sure what the solution is right now though. > > > > > > > > Cheers, > > > > Jeremy > > > > > > > > On 15/11/2007, John Kaputin <[EMAIL PROTECTED]> wrote: > > > > > With Woden M8 in progress and (hopefully) a Woden 1.0 release to > > > follow we > > > > > need to think about stabilizing/finalizing the Woden API. The 1.0 > > > release > > > > > should define our 'committed' API. Some API issues have been or > are > > > being > > > > > addressed via JIRAs. Some other issues may require more > discussion > > on > > > the > > > > > woden-dev mailing list before they're ready to track as JIRAs. > > > > > > > > > > To capture such issues and provide background info to prompt > further > > > > > discussion, I have created an API Review page on the Woden Wiki > [1]. > > > See > > > > > the intro there for more details, read through the issues (2 so > far) > > > and > > > > > post your ideas to the list. > > > > > > > > > > [1] http://wiki.apache.org/ws/FrontPage/Woden/APIReview > > > > > > > > > > regards, > > > > > John Kaputin > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
