Forum

by Jocelyn-Fiat (modified: 2018 Sep 05)

:: Welcome :: Forum

Eiffel related groups and forums:

Check the latest messages:

    Discussion regarding the Eiffel programming language and various supporting tools.
  • Jan 27
    Re: [eiffel-users] Conceptual meaning of undefine
    “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
  • Jan 27
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 26
    RE: [eiffel-users] Conceptual meaning of undefine
    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.)
  • Jan 26
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 26
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 26
    RE: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 26
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 26
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 26
    Re: [eiffel-users] Conceptual meaning of undefine
    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,
  • Jan 26
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 25
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 25
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 25
    Re: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 25
    RE: [eiffel-users] Conceptual meaning of undefine
    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
  • Jan 25
    Conceptual meaning of undefine
    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
  • Jan 22
    Antw: [EXT] Re: [eiffel-users] Locations of open-source versions of EiffelStudio and libraries
    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
  • Jan 21
    Re: [eiffel-users] Locations of open-source versions of EiffelStudio and libraries
    Also--I await Bertrand's revised version of the ECMA standard with great anticipation.
  • Jan 21
    Re: [eiffel-users] Locations of open-source versions of EiffelStudio and libraries
    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!
  • Jan 21
    Re: [eiffel-users] Locations of open-source versions of EiffelStudio and libraries
    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,
  • Jan 21
    RE: [EXT] Re: [eiffel-users] Contracts & Multiple Inheritance
    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
  • Jan 21
    Re: [eiffel-users] Locations of open-source versions of EiffelStudio and libraries
    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
  • Jan 21
    Re: [eiffel-users] Locations of open-source versions of EiffelStudio and libraries
    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,
  • Jan 21
    Antw: Re: [EXT] Re: [eiffel-users] Contracts & Multiple Inheritance
    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
  • Jan 21
    Re: [eiffel-users] Contracts & Multiple Inheritance
    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
  • Jan 21
    Re: [eiffel-users] Contracts & Multiple Inheritance
    "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
  • See more ...