guendel@exunido.uucp (Andreas Guendel) (08/23/89)
Dear Eiffel Community, since I plan to teach Object-Oriented Design I have read (among others) the book "Object-oriented Software Construction". From my history I am a Smalltalk-80 programmer but for padagogical reasons I would prefer to take a typed OO-language as example, so Eiffel is a good candidate. Obviously in any language there are a lot of design decision which become a matter of criticism, for example the Type-Security discussion on Eiffel. My first question belongs to this area: As I understand typing, it is a form of statically checkable assertions. The argument-types of a routine belong to its preconditions, the result- type to its postconditions. Therefor it seems reasonable to have the same rules for typing and for assertions in case of inheritance: Weakening the preconditons of a redefined routine in a subclass corres- ponds to allow a supertype of the arguments, making the postcondition stronger corresponds to return a subtype of the old return-type. This treatment of assertions (the dynamic ones) in proposed in the book to guaranty an is-a relation between the subclass and its superclass. But as argued by Bertrand Meyer in one of his postings to this group (and as many examples show), for the type-assertions weakening the preconditions does not conform to practise. This makes it very difficult to talk about real "is-a" inheritance, doesn't it? How shall I explain this problem in my course? Another point is the multiple-inheritance problem. As in the book this feature is often used for implementation convienience: there is no way to argue that a fixed-stack "is-a"n array. So I would prefer to use the implementation-variant, in spite of its little overhead. I only accept multiple inheritance if an object really belongs to more than one concept (see below), at least in a course on principles of OO Software Construction. But this is not really a problem since I can leave out those examples. More difficult to understand is the default hiding of inherited features. Since "is-a" inheritane is the basic principle of the design-method and assumed by default by the type-checker, it would probably be a better default to export all the features exported by the superclass. Anything that may obscure "is-a" inheritance (renaming, redefinition, hiding) would have to be explicitly stated (keyword: hide). Does anyone know the reason behind this decision? The LAST POINT concerns the discussion on genericity versus inheritance and constrained genericity in Eiffel (this is of course an important theme in a planed course). The solution proposed in the book (e.g. to get a comparable version of some class) does not really provide the benefits of constrained genericity: Neigther can existing elements of the base-class be used as comparables, nor can elements of the comparable version be used as elements of the base-class. In oposite to the fixed-stack example above, here multiple inheritance would be justified: an xyz_comparable "is-a" xyz and "is-a" comparable! In a language with constrained genericity this unconvinience doesn't appear: the elements of a sorted list are normal elements of their base- type with some operations renamed for use inside the sorted-list stuff. It would be very important for my course if someone would answer my questions or correct my opinions where they need to be corrected. Reply eigther by email or directly to this group. Thanks in advance and sorry for the length of this posting, Andreas
bertrand@eiffel.UUCP (Bertrand Meyer) (08/24/89)
From article <1567@laura.UUCP> by guendel@exunido.uucp (Andreas Guendel): > Thanks in advance and sorry for the length of this posting, Thanks in advance and sorry for the brevity of this posting, > Another point is the multiple-inheritance problem. As in the book this > feature is often used for implementation convienience: there is no way > to argue that a fixed-stack "is-a"n array. Sorry. It is *not* a matter of convenience. One can argue about this for years but to me an array-stack is an array, without any hesitation or qualification. The full discussion would require more subtlety but, in a nutshell, information hiding is NOT always desirable. (Yes, this is contrary to accepted wisdom, but too much of even apple pie can be dangerous to your health.) In the Eiffel view, information hiding does not apply to inheritance. Other approaches are possible and I appreciate the arguments for some of them (see e.g. the article by Alan Snyder referenced in the bibliography of OOSC) but I know of no one which is as simple, consistent, and practical. > The LAST POINT concerns the discussion on genericity versus inheritance > [...] The solution proposed in the book (e.g. to > get a comparable version of some class) does not really provide the > benefits of constrained genericity: Neither can existing elements of > the base-class be used as comparables, nor can elements of the comparable > version be used as elements of the base-class. OOSC did not cover (except through a hint in exercise 19.5) an important mechanism which has been present in all Eiffel implementations distributed since July of 1988: constrained genericity. This, I think, solves the problems raised here by Prof. Guendel. Constrained genericity is the ability to specify a class as e.g. class SORTED_LIST [T -> COMPARABLE] meaning that any actual generic parameter used for T must be a descendant of COMPARABLE, with the operations <=, > etc., equipped with the proper assertions. > Since I plan to teach Object-Oriented Design I have read (among others) > the book "Object-oriented Software Construction". From my history I am > a Smalltalk-80 programmer but for padagogical reasons I would prefer to > take a typed Object-Oriented-language as example, so Eiffel is a good > candidate. I think if Prof. Guendel and his students use the Eiffel environment, not just as a paper concept but as a practical framework for designing and implementing good software, then they will have a much better feel for what this technology really brings. An object-oriented design course which would spend its time quibbling about language features would be rather boring. What the students need to do is to build software, using a good object-oriented environment together with the associated methods, tools and libraries, and appreciate the results. If Prof. Guendel's students do get this opportunity, I have no doubt they will understand that our design decisions, including those which may appear shocking from a superficial analysis, are rooted in a careful examination of the goals, needs and challenges of practical software development. -- Bertrand Meyer bertrand@eiffel.com
mccaugh@s.cs.uiuc.edu (08/25/89)
This sounds like one of the most thoughtful notes I have ever had the pleasure to read in a notesfile: in fact, until I read this note, I was rather skeptical about the true intellectual content of object-oriented programming (smacking of band-wagon fever, no doubt)...anyway, if you haven't read the base note, please do: it is indeed most thought-provoking. My own request is more urbane: why Eiffel? I mean, we have SmallTalk-80, C++, LOOPS and FLAVORS, etc...what does Eiffel add?
guendel@exunido.uucp (Andreas Guendel) (08/28/89)
In my first posting I claimed: > Another point is the multiple-inheritance problem. As in the book this > feature is often used for implementation convienience: there is no way > to argue that a fixed-stack "is-a"n array. In his answer Bertrand Meyer replied: > Sorry. It is *not* a matter of convenience. One can argue about this for > years but to me an array-stack is an array, without any hesitation or > qualification. Concerning the years of discussion he is right. But as I have learned, an array is a data-structure to which elements can be stored at a given index and can be retrieved using the same index. The fixed-stack of the Eiffel- book does not provide these functions. Bertrand Meyer proceeds: > The full discussion would require more subtlety but, in a nutshell, > information hiding is NOT always desirable. (Yes, this is contrary to > accepted wisdom, but too much of even apple pie can be dangerous to > your health.) In the Eiffel view, information hiding does not > apply to inheritance. Bertrand Meyer misunderstood my point. I did not propose to hide the implementation of superclasses against their descendants (though this is an interesting question) but I argued against USING inheritance in the stated situation. If fixed-stack is implemented as a subclass of array, the type-checker will assume that an instance of fixed-stack can be used wheresoever an array is expected. But if you do that at any place, the algorithm given by Meyer to make Eiffel type-save will raise an error since NO function on arrays can be called on fixed-stacks. As I understood this algorithm it should be used in situations where a class NEARLY CONFORMS to the specification of its superclass but has SOME methods with restricted argument-types or which are hidden to ensure the integrity of the subclass's instances state. I was lucky to hear that current Eiffel includes constrained genericity. There are two questions to this point, a theoratical and a practical one: 1. Do you (mainly Bertrand Meyer) share my opinion that inheritance can not adaequately model constrained genericity? 2. (For those as me who do not have any information on current Eiffel) Does Eiffel provide the mechanism of renaming some methods of parameter- classes for the use inside the generic class? This is necessary to handle existing classes which provide the needed functionality under different names without building subclasses to make them "real" comparables. Without this the problems of the prior solution keep existing. At the end of his posting Bertrand Meyer concluded: > If Prof. Guendel's students do get this opportunity [to use the Eiffel > environment to build their own software], I have no doubt > they will understand that our design decisions, including those which > may appear shocking from a superficial analysis, are rooted in a careful > examination of the goals, needs and challenges of practical software > development. Thanks for the "Prof." but at our university there are so many students that non-Professors and even non-Doctors as me are encouraged to give lessons on their area of research. I understand Meyer's last sentence as a first but not exhaustive answer to my questions concerning parameter- and result-types as special assertions and the default hiding of inherited features. Thanks so far, also to those who responded by mail, Andreas
marku@cheops.eecs.unsw.oz (Mark Utting) (08/31/89)
From article <1573@laura.UUCP>, by guendel@exunido.uucp (Andreas Guendel): > In my first posting I claimed: > >> Another point is the multiple-inheritance problem. As in the book this >> feature is often used for implementation convienience: there is no way >> to argue that a fixed-stack "is-a"n array. > > If fixed-stack is implemented as a subclass of array, the type-checker will > assume that an instance of fixed-stack can be used wheresoever an array is > expected. But if you do that at any place, the algorithm given by Meyer to > make Eiffel type-save will raise an error since NO function on arrays can > be called on fixed-stacks. As I understood this algorithm it should be used > in situations where a class NEARLY CONFORMS to the specification of its > superclass but has SOME methods with restricted argument-types or which are > hidden to ensure the integrity of the subclass's instances state. > > Andreas In my research work on verifying systems that use multiple inheritance I have found that it is semantically useful to distinguish between `SUBTYPE' inheritance (eg. CHILD1 is a subtype of PARENT) and `REUSE' inheritance (eg. CHILD2 shares PARENT's implementation or specification). Practically, the difference is that CHILD1 objects are intended to behave like PARENT objects, whereas CHILD2 objects may behave *quite* differently. This means that the type system should not allow CHILD2 objects to be assigned to PARENT variables (because they are not *intended* to behave similarly). In the above example, it is my opinion that `fixed-stack' should inherit from `array' via REUSE inheritance rather than SUBTYPE inheritance. Some object oriented languages do have both kinds of inheritance, and several papers I have read have stated that it is desirable to distinguish between these different uses of inheritance. There is a good discussion of various inheritance relations in "Inheritance as an Incremental Modification Mechanism" or "What Like Is and Isn't Like", by Peter Wegner and Stanley Zdonik in ECOOP '88 proceedings (LNCS 322, Springer-Verlag). Extending Eiffel to distinguish between `normal' inheritance (which in Eiffel is more or less SUBTYPE inheritance) and REUSE inheritance would add to the type security of the language, by allowing programmers to specify when they do not wish a child to have to be compatible with one of its parents. There was a posting to this newsgroup early this year from a company using Eiffel for very large systems which said they were doing exactly this, informally. From memory, they just put a comment "-- USE" before some of the class names in the `inherit' clause. Mark Utting, Dept.Comp.Sci, UNSW, PO Box 1, Kensington, NSW, Australia 2033 // ACSnet,CSNET: marku@cheops.unsw.oz // BITNET/ARPA: marku%cheops.unsw.oz@uunet.uu.net \// UUCP: ...!uunet!munnari!cheops.unsw.oz!marku
simpson@usc.edu (Scott Simpson) (09/07/89)
I have some Eiffel questions. 1. Why is the semicolon a statement separator rather than a statement terminator? From the Ada Rationale section 2.2 Declarations and statements are always terminated by semicolons - this differs from the Pascal practice, in which a semicolon is used as a separator. The Ada convention simplifies the insertion of another declaration or statement: normal layout places the semicolon at the end of a line and thus, where semicolons are separators, insertion of a line often entails changing the previous line as well. This is an argument against separators between items that are likely to be on separate lines. We want each line to be a complete unit - therefore including a terminator - so that adding a line does not require changing a previous line. (Fortran achieves this by having the end of line be a terminator). The use of semicolons as terminators aids recovery by the compiler after finding a syntax error; recovery from omission of the semicolon itself is usually quite simple for the parser. Finally, comparative analyses of programmer errors have shown the use of semicolon asa terminator to be less error-prone than its use as a separator [GH 75]. 2. What's the status of adding concurrency to Eiffel? 3. Is there a InterViews-like UIMS done in Eiffel? 4. Are there Xlib, X toolkit, HP widgets, Sony widgets, etc. bindings done in Eiffel? Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)
bertrand@eiffel.UUCP (Bertrand Meyer) (09/10/89)
From <5400@wiley.UUCP> by trwarcadia!simpson@usc.edu (Scott Simpson): > 2. What's the status of adding concurrency to Eiffel? In progress > > 3. Is there a InterViews-like UIMS done in Eiffel? > > 4. Are there Xlib, X toolkit, HP widgets, Sony widgets, etc. bindings > done in Eiffel? The current 2.2 version includes a windowing and graphics library which is simple, robust (we hope), easy to use, portable. To all the extent possible, it saves programmers from having to dive into the (somewhat horrible) details of X Windows, offering clean abstractions such as window, menu, event, mouse, figure, circle etc. The library is not yet a full-fledged mechanism for constructing user interfaces. Work on tools and abstractions of a higher level is in progress. We are aware of several existing developments by users who have produced high-level Eiffel graphics systems and UIMS (one in particular based on Open Look). -- -- Bertrand Meyer bertrand@eiffel.com
ajk@goanna.cs.rmit.oz.au (Alan Kent) (03/19/91)
Recently I have been looking at using Eiffel for building a research database system. We have a current system in C, but with big changes afoot, I considered it a good time to look around and see if there was a better language. The current system is about 100,000 lines of code. Eiffel looked good in many ways (being object oriented and there was a possibility of going towards an object oriented database system), but I had a few questions about the langauge. I am sorry if these are commonly asked questions, but I have only just started reading this group. I have used an object oriented language before, but have not attempted any large scale projects in such a language. From what I have read, Eiffel does not allow classes to be manipulated as objects. In particular, I would find it useful to be able to pass a class as a parameter and then create instances of that class. Consider for example an indexing mechanism class. I would like to be able to write a series of subclasses of "IndexingScheme" which all behave in a similar way, but implement different schemes (inverted files, linear hashing, hybrids and so on). When I create an index on a table, I need to create an instance of this class. Ideally, I do not want to have to have a table of known indexing techniques, but there seems to be no way around this, especially since to create an object you have to declare a variable of the object type first. Is there a common simple solution to this? Does an Eiffel interpreter exist? Or else dynamic object module loading? For example, can a database designer define a new class in Eiffel which could be used as a new type (for example, define a Date class). Another example, if I have a database kernel, can I download (application specific) code to the kernel and have it run there (for efficency). From my limited understanding of how Eiffel is compiled, this does not seem possible. Is there any light weight process support in Eiffel (or the Eiffel libraries)? I have also heard the language is still changing. How significantly? If we write a large program in it, how difficult is it going to be to change to keep it working with later revisions? There are a few other little things I do not like, but with the combination of Generic Types, Multiple Inheritance and Storable (which I assume can convert any object graph into a byte stream - which I could then store as a database record or send to another program), Eiffel looked very nice. Thanks for any information people can pass on... ------------------------------------------------------------------------------- Dr. Alan Kent, ACSNET: ajk@goanna.cs.rmit.OZ Key Center for Knowl. Based Sys., INTERNET: ajk@goanna.cs.rmit.OZ.AU Victoria University of Technology, JANET: ajk%au.oz.goanna@uk.ac.ukc RMIT Campus, BITNET: ajk%goanna.cs.rmit.OZ.AU@relay.cs.net Dept. of Comp. Sci., UUCP: ..!uunet!goanna.cs.rmit.OZ.AU!ajk GPO BOX 2476 V, Phone: +61 3 660 2992 Melbourne, 3001, AUSTRALIA Fax: +61 3 662 1617
ajk@goanna.cs.rmit.oz.au (Alan Kent) (03/19/91)
In article <4998@goanna.cs.rmit.oz.au>, ajk@goanna.cs.rmit.oz.au (Alan Kent) writes: > Recently I have been looking at using Eiffel for building a research > database system... Also, what sort of debugging support does Eiffel have? Do you simply have to use dbx, or are there good online debuggers available yet. An interpreter would help here I guess as you could almost use it as your debugger. > Thanks for any information people can pass on... ajk@goanna.cs.rmit.oz.au