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

["Lance Phillips" <lphillips@xxxxxxxxxxxxxx>]

We were really hoping for a solution that did not involve regenerating all
of our metamodels (of which we have over10 now).

thanks,

lp
"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
>