“I was thinking following the discussions about some inheritance pattern into which the father I am has an ability to write, my children not having it still but inheriting from me.” I think this is a case of over anthropomorphism. The inheritance relationship is much tighter in OO. Perhaps a

Hi Alexey, This is something that the C# folks should accept, because C# permits it too. I just tried it. public class A { protected virtual void Foo() {} } public abstract class B : A { protected abstract override void Foo(); } No complaints from the C# compiler! https://stackoverflow.com/que

Dear Alexey, Very simple. B restarts the abstraction chain from A in a clean(er) slate. In the ideal refinement scheme, abstract concepts come first, then you refine repeatedly. Simplistic textbooks mention only this. (Suggestions for non-simplistic textbooks will be provided on request.)

I will try an example that I did some time ago. We all know that every class inherit ANY. Also, we all know that ANY have some mechanism like `is_equal`, `copy`, `twin`, `out`, etc. Some time ago, I was creating a library that used a lot of C pointers and I create an abstract class to represent

Thank you all for your answers. I tried them all many times - the all do not convice single-inheritance minded folks :-) Sorry ... last try :-) class A foo do end end deferred class B inherit A undefine foo end end That is the thing they (Java-C#-etc.) do not accept conceptually ... On

Hi Alexey Attached is a "vintage" doc I created and have maintained over the years. In the "undefine" section, there is a very basic example that _might_ help. R -------- Original Message -------- Subject: Re: [eiffel-users] Conceptual meaning of undefine From: Alexey Kanatov

Hi, I was thinking following the discussions about some inheritance pattern into which the father I am has an ability to write, my children not having it still but inheriting from me. On this case my ability to write is an ability the will have, but in their way so the inheritence of me will

Hi Alexey. My second example has a little twist that I did not mention. I have no use for SET_OF_SETS apart from factoring out features of SET_FAMILY and SUBSET_FAMILY. Normally, I would not need to undefine anything for that, but MY_SET has some class features, and features that use such class

Guys - please understand me right - my personal experience (being co-author of Visual Eiffel compiler implementing all feature adaptation mechanisms) and delivering lectures to students about systematic software design and development is one thing but another is talking to Java, C#, C++, JS,

Hi Rosivaldo - I liked your example about some common class - " But you may have to undefine a feature even in single inheritance. For example, suppose you have an effective class MY_SET, that implements the concept of a set; you also have effective descendant classes, e.g. SET_FAMILY and

Hey Alex! I cannot think of a specific example where I have created a new descendant class from a concrete implementation parent and the new class is deferred. However, I know we have done it. Restricting a descendant to be concrete if the parent(s) are concrete would be a mistake. As others

Hi, mentioning also that maybe a feature is implemented in a hierarchy and you want it to be deferred for its descendents.... On Mon, Jan 25, 2021 at 5:32 PM Rosivaldo Fernandes Alves < rosiv...@gmail.com> wrote: > Hi Alexey. > > What goes below comes from my little experience. Others may add

Hi Alexey. What goes below comes from my little experience. Others may add more examples. Mostly, undefining will be necessary when a class inherits from two classes and they have different implementations for the same feature; if one of those implementation fits your needs, you undefine one

Hi Alexey In my experience, it is most helpful when there is multiple inheritance and more than one ancestor has an implementation of that feature. This occurs very commonly when creating custom GUI controls, or when your system has several shared ancestors, but occurs commonly enough elsewhere

Dear all, Different people ask me about the practical need of undefinition in case when we have effective class and after undefining of one of its features we come to a child class which will be deferred in such situation. So, conceptually we go down the inheritance hiearchy from the concrete

Nachricht : > Also--I await Bertrand's revised version of the ECMA standard with great > anticipation. Makes me wonder: Is there a "language design group" that discusses new features heavily before they get implemented in

Also--I await Bertrand's revised version of the ECMA standard with great anticipation.

LOL -- my mistake then. My grandmothers name was Vivien and I've not heard of being used for boys/men before. Nevertheless--glad you are aboard!

Hah! Well I appreciate the sentiment, but I'm sorry to disappoint: in France Vivien is actually a name given to boys, not girls! > In case you missed it—I was just the proud recipient of a self-made > design flaw (bug) that was revealed by way of Design by Contract. When > such things happen,

The purpose of undefining is to remove the _implementation_ coming from that branch of the ancestry. The purpose of redefining is to replace or expand upon the _implementation_ coming from that branch of the ancestry. The signature and contracts remain and are unchanged, except as permitted by

Vivien! Thank you for an excellent discourse of your thoughts. Moreover—thank you for being a bright and wonderful lady willing to wade in with the "boys club" and show us that women make fantastic engineers! Nearly every female engineer I have met has been an outstanding individual and

Hi everyone, Le 16/01/2021 à 14:02, Eiffel Users a écrit : > The GPL-licensed source code, now updated to version 19.12 , is > available in the following two locations [...] I want to thank EiffelSoftware for this and also use the occasion to say hello as this is my first message here,

Nachricht : > "My guess is because you undefine to share and redefine, and the > redefinition > needs to ful fill all postconditions." > > Again—the purpose of undefining is that the ancestor routine no longer > applies. As

I will also say this rather clearly—running into this may (in fact) point to a flaw in my design rather than how such a situation is handled. For example: It may well be that the notion of a SUBMARINE having a "default_drive_type" is simply wrong. This is especially true if a SUBMARINE is

"Logically, the contract must hold. Always. You may weaken the precondition but can only strengthen the post-condition and the invariant." Again—no, the contract does not necessarily have to hold. It must for the ancestor, but in this case, the descendant is clearly saying, "I cannot offer that