Author Topic: Live-update in descendant classes (Read 5625 times)

du-it · « **on:** November 15, 2005, 09:36:36 am »

I wonder if it is possible with EA that changes made in a parent class will be reflected in a descendant class?

I have created a class A with some attibutes and operations. Another class B is a descendant of class A and I choosed some operations to be overriden by class B. Some time later I choosed to change the name of an operation in class A but this is not reflected in class B.
Is this a bug or intended?

Furthermore I figured out that even operations which are declared as final/const in class A are offerd to be overriden in the subclass. Since they are final they should not appear in the dialog for operations to be overriden/implemented.

thomaskilian · « **Reply #1 on:** November 16, 2005, 02:28:39 am »

What do you expect to be promoted? Name, Parameter and/or Code changes? If you once decided to override the implementation, then you have an independant copy. So this is likely intended.

du-it · « **Reply #2 on:** November 16, 2005, 02:56:47 am »

Well, I think I see what you mean but:
Lets say I have a parent class with an operation named 'abc' and a subclass in which I chose to override this method.
If I then change the name (not via new operation but via changing its name) I would expect that the name will be updated in all subclasses. So renaming 'abc' to 'def' in the parent class should result in renaming the operation to 'def' in the subclass as well.
Of course, I overrode this operation but the intention ist just to override the operations content and not its signature (since this would be no overriding but a different operation).

What about my suggestion to not show final methods in the overriding dialog? Do you agree?

thomaskilian · « **Reply #3 on:** November 16, 2005, 03:09:54 am »

I have no opinion on that

so I leave it to others to comment. Also it's only my comment on renaming. Other might join your suggustion

Eve · « **Reply #4 on:** November 20, 2005, 01:16:29 pm »

I remember this discussion (or one very similar) at least once before in the forums. At that stage there were a few people pushing for both "do propogate" and "don't propogate".

sargasso · « **Reply #5 on:** November 20, 2005, 02:36:35 pm »

A related thread on interfaces - my argument still applies.
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1128104162;start=4#4

bruce

Paolo F Cantoni · « **Reply #6 on:** November 20, 2005, 04:02:50 pm »

Quote

A related thread on interfaces - my argument still applies.
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1128104162;start=4#4

bruce

As I did on the original thread, I concur with bruce. However, at a minimium the user should be able to specifiy:

Automatically inherit nothing
Automatically inherit everything
Ask me for what to do

Hans · « **Reply #7 on:** December 04, 2005, 07:07:04 am »

So, all in all there is a cry for an "inherit down" option being settable on a class and/or method level, and I second that!

Hans

Paolo F Cantoni · « **Reply #8 on:** December 04, 2005, 03:29:46 pm »

Quote

So, all in all there is a cry for an "inherit down" option being settable on a class and/or method level, and I second that!

Hans

It must actually be specified on a per relationship level. That is, each relationship must hold details of what is to be inherited/realized or not (and how). With multiple inheritance the model needs to allow each path to propagate its contract

Don't forget about cascade effects...
Paolo

Sparx Systems Forum

News: