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

["Randall Hauch" <rhauch@xxxxxxxxxxxxxx>]

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
>