Artem,
Comments below.
Artem Tikhomirov wrote:
Ed,
I'm kinda stuck. To me, this sounds like I'm using Suppress
Notification option incorrectly (what is it about then, if not "do not
generate notifications"?) and, moreover, "Changing the way one
generates code (i.e. with or without notifications) breaks fundamental
EMF promise to keep integrity of the model (opposite references set).
Perhaps, option's name should say "Suppress Integrity" then? ;)
To be really politically incorrect, this option was provided for a
large division of a big company who liked to do what I call "negative
shopping". You give them a fully functional useful system and they
want to shop away parts of it because they don't understand how they
will need those parts and will feel far more comfortable without them.
In the end, you keep providing these negative shoppers with more and
more things, only to find out in the end that they didn't really want
to buy any of your goods in the first place but rather were simply
looking for excuses not to buy any of it. I'd just as soon deprecate
the whole thing as I would to try to make it work better than the
semi-useless state that it's in. The only reasonable way to achieve
fully functional lists that don't notify is to specialize this method:
@Override
protected boolean isNotificationRequired()
{
return owner.eNotificationRequired();
}
But I don't intend to duplicate the entire hierarchy for that purpose
given how little value such code bloat would actually provide. Easier
would be to specify your own root extends class and specialize
eNotificationRequired to always return false, but of course as I
mentioned if there are no adapters, no notifications are produced so
what's to be substantially gained to break the general contract that
all EObjects can produce notifications when needed?
Artem
Well, I thought containment is kind of fundamental relation, and
eContainer() not null for contained object seems reasonable
expectation,
One person's fundamental seems to be another person's
complex/unnecessary...
even if it causes few(?) extra
implementation classes.
No, not just a few. Enough to cause a significant of bloat....
Am I wrong assuming Suppress
Notification should not affect bi-directionality of the containment?
Wrong is perhaps too strong a word, but certainly you're expectations
are too high. What exactly are you hoping to gain by suppressing
notifications?
With Suppress Notification option, I try to get a model that is
instantiated once, processed (read), and discarded.
If there are no listeners, notifications aren't produced so I'm not
sure there's much to be gained.
There are no model modifications expected
(other than assembling or reading/loading it from resource), hence no
notifications needed. I understand that eNotificationRequired() is
effective and is not too much code to get rid of, nevertheless, once
you face an obstacle, it's out of curiosity to find out ;)
It's not worth worrying about, in my opinion.
Thanks.
Artem.
|