Home » Modeling » EMF » Suppress Notification and containment list
| |
Re: Suppress Notification and containment list [message #484914 is a reply to message #484898] |
Wed, 09 September 2009 16:29 |
Artem Tikhomirov 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 |
Ed Merks Messages: 33142 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 |
Artem Tikhomirov 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 |
Ed Merks Messages: 33142 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/
|
|
| |
Goto Forum:
Current Time: Mon Apr 29 06:36:38 GMT 2024
Powered by FUDForum. Page generated in 0.03525 seconds
|