Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Suppress Notification and containment list
Suppress Notification and containment list [message #484891] Wed, 09 September 2009 15:53 Go to next message
Artem Tikhomirov is currently offline Artem TikhomirovFriend
Messages: 222
Registered: July 2009
Senior Member
Hello,

I came across use of BasicInternalEList for containment lists when I turn
Suppress Notification option to true for my model. The list implementation
doesn't update eContainer of an object being added to the list, and I feel
this is not right - with parent.getChildren().add(child);
child.eContainer() is null, not parent as it used to be.

Am I wrong assuming Suppress Notification should not affect
bi-directionality of the containment? Perhaps ordering of
"getGenModel().isSuppressNotification()" and
"genFeature.isEffectiveContains()" in the
GenClassImpl#getListConstructor() is the cause?

Thanks

Artem.
Re: Suppress Notification and containment list [message #484898 is a reply to message #484891] Wed, 09 September 2009 16:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Artem,

Comments below.


Artem Tikhomirov wrote:
> Hello,
>
> I came across use of BasicInternalEList for containment lists when I
> turn Suppress Notification option to true for my model. The list
> implementation doesn't update eContainer of an object being added to
> the list, and I feel this is not right - with
> parent.getChildren().add(child); child.eContainer() is null, not
> parent as it used to be.
Yes, it doesn't sound quite wonderful, but there aren't non-notifying
versions of the huge number of list classes nor would I ever consider
doubling the number of these things.
>
> 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?
> Perhaps ordering of "getGenModel().isSuppressNotification()" and
> "genFeature.isEffectiveContains()" in the
> GenClassImpl#getListConstructor() is the cause?
>
> Thanks
>
> Artem.
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Suppress Notification and containment list [message #484914 is a reply to message #484898] Wed, 09 September 2009 16:29 Go to previous messageGo to next message
Artem Tikhomirov is currently offline Artem TikhomirovFriend
Messages: 222
Registered: July 2009
Senior Member
Ed,

Well, I thought containment is kind of fundamental relation, and
eContainer() not null for contained object seems reasonable expectation,
even if it causes few(?) extra implementation classes.

>> 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. 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 ;)


Thanks.

Artem.
Re: Suppress Notification and containment list [message #484945 is a reply to message #484914] Wed, 09 September 2009 20:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Artem,

Comments below.

Artem Tikhomirov wrote:
> Ed,
>
> 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.
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Suppress Notification and containment list [message #485023 is a reply to message #484945] Thu, 10 September 2009 09:41 Go to previous messageGo to next message
Artem Tikhomirov is currently offline Artem TikhomirovFriend
Messages: 222
Registered: July 2009
Senior Member
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? ;)

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.
>>
>>
Re: Suppress Notification and containment list [message #485123 is a reply to message #485023] Thu, 10 September 2009 14:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020602020605030903070008
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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.
>>>
>>>
>
>

--------------020602020605030903070008
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Artem,<br>
<br>
Comments below.<br>
<br>
Artem Tikhomirov wrote:
<blockquote
cite="mid:bc338d5b6d2b1e257ce0266d8770e022$1@www.eclipse.org"
type="cite">Ed,
<br>
<br>
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? ;)
<br>
</blockquote>
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".


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Suppress Notification and containment list [message #485181 is a reply to message #485123] Thu, 10 September 2009 18:06 Go to previous message
Artem Tikhomirov is currently offline Artem TikhomirovFriend
Messages: 222
Registered: July 2009
Senior Member
Ed, thanks for the explanation. I couldn't have imagined one could "bend"
EMF team to get useless code in there ;) Next time, just tell me "it
option is crap. period" and that would suffice. Sorry for wasting your
time with that.

Thanks again.

Artem.
Previous Topic:sharing a single read-only resource instance between resource sets
Next Topic:EContentAdapter for all new Model instances
Goto Forum:
  


Current Time: Fri Mar 29 14:01:21 GMT 2024

Powered by FUDForum. Page generated in 0.02526 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top