[news.eclipse.tools.emf] Re: EcoreEList help

[Ed Merks <merks@xxxxxxxxxx>]

Randall,

I think it's best that you tweak the code for your purposes.  The assumption
that two EObjects are equal only if they are "==" is quite prevalent and I
don't want to go in the direction of backing away from that since the
performance benefit of relying on == everywhere is very significant.  Sorry.

Randall Hauch wrote:

> Unfortunately, your suggestion doesn't work for lists that have more than 4
> elements.  Here's a snippet from the EcoreEList's contains(Object) method:
>
>       if (size > 4)
>       {
>         if (isContainment())
>         {
>           if (!(object instanceof EObject)) return false;
>           InternalEObject eObject = (InternalEObject)object;
>           return
>             eObject.eContainer() == owner &&
>               (hasNavigableInverse() ?
>                  eObject.eContainerFeatureID() == getInverseFeatureID() :
>                  InternalEObject.EOPPOSITE_FEATURE_BASE -
> eObject.eContainerFeatureID() == getFeatureID());
>         }
>         // We can also optimize single valued reverse.
>         //
>         else if (hasNavigableInverse() && !hasManyInverse())
>         {
>           return object instanceof EObject &&
> ((EObject)object).eGet(getInverseEReference()) == owner;
>         }
>       }
>
>       boolean result = super.contains(object);
>
> Only the call to "super.contains(object)" in the last line of the snippet
> will make use of the "useEquals()" method, but the method returns from the
> previous block if the size() > 4.  Unfortunately, the only way to alter the
> behavior of the preceding lines in this snippet is to completely override
> the 'contains(Object)' method - which is significant work.
>
> Although this does work for typical uses of EMF, it prevents use of EMF in
> an extended way.  Changing the above code to use the equals is a simple
> change, would make this code much more tolerant of the way EMF is extended,
> and yet add very little overhead (after all, the method's optimization does
> only one comparison anyway, meaning its a single call to 'equals()').
>
> Randall
>
> "Frank Budinsky" <frankb@xxxxxxxxxx> wrote in message
> news:3F54E2D9.8A2D4DDA@xxxxxxxxxxxxx
> > Lance,
> >
> > The == and > 4 checks are purely for performance. Ed has tuned the
> performance
> > on this class to squeeze out every last CPU cycle. You can change the ==
> to
> > equals() by overriding the useEquals() method to return true, for example
> in an
> > anonymous subclass:
> >
> >   public EList getFoo()
> >   {
> >     if (foo == null) {
> >       foo = new EObjectXXXEList(Foo.class, this, ...)
> >       {
> >          protected boolean useEquals() { return true: }
> >        }
> >     }
> >     return foo;
> >   }
> >
> > You'll probably want to change the generator template to do this.
> >
> > Frank.
> >
> >
> > Lance Phillips wrote:
> >
> > > All,
> > >     We are using EMF as the model layer of our application.  However,
> there
> > > is one catch, we are wrapping the EObjects with java dynamic proxies.
> We
> > > are only wrapping the primary objects, we are not wrapping any of the
> lists.
> > > This is presenting a significant problem in regard to the EcoreEList.
> > >
> > > In the contains method, all the ==  checks for eObject.eContainer() ==
> owner
> > > fail for us due to the fact that eObject.eContainer() is a proxy while
> owner
> > > for the eList is not.  Is there any reason these checks could not be
> changed
> > > to .equals()?
> > >
> > > Also, why the check for size > 4????  This was a bear to track down due
> to
> > > the fact that none of our test cases failed because the test models
> where
> > > small models that fell through to the super.contains() check.  Is there
> any
> > > reason this method couldn't simply eliminate the entire size > 4 if
> block
> > > all together?
> > >
> > > thanks,
> > >
> > > Lance Phillips
> >