Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!kepler1!fcaggian From: fcaggian@kepler.com (Frank Caggiano) Newsgroups: comp.lang.eiffel Subject: Re: Assertions and deferred routines Message-ID: <445@kepler1.kepler.com> Date: 19 Oct 90 14:47:36 GMT References: <443@kepler1.kepler.com> <420@eiffel.UUCP> Organization: Kepler Financial Mgmt., Setuket, NY Lines: 57 Thanks to all for clearing up this problem. I was lead astray by Section 10.3.4 'Specifying the semantics of deferred routines' in the Book. Starting at the bottom of page 236 with the paragraoh begining 'Only with assertions do deferred classes attain their full power. ... '. This paragraph in particular seems to imply that assertions hold for actual implementaions of deferred routines. In fact further on in the paragraph it is written, 'all variants of push in descendents of STACK are constrained by the above specification.' I was further confused by the nomenclature used. Pages 256 seemed to deal with redefinition and I was under the impression that creating an efective instance of a deferred routine was definition. This confusion arose from page 48 of 'Eiffel: The language' bottom of the page 'DEFINITION: defining a feature' which uses the keyword 'define' which isn't even mentioned (as far as I can tell) in the Book. (see also page 39 of 'Eiffel: The language' section 7.7 4th bullet item). Anyway this could probably go on for quit a while more and not accomplish much else. One thing I feel would help avoid these misunderstandings would be more timely output from ISE. What I mean by this is a compilation of issues, know bugs etc. To both of my last postings I was told that what I was asking had been mentioned in a previous posting. (Dr. Meyer refered me back to a posting in January of this year) Does ISE have an archive of this group that is avaliable? As we only received Eiffel in May of this year I wasn't reading the group back in Jan. (in fact I was gainfully unemployed in Jan, not reading any netnews). In fact looking at what I just wrote it really doesn;t matter if ISE has the archive or not. As a customer of ISE I expect to be informed of these issues directly. This especially applies to know problems in the documentaion. Bugs in both the documentation and software are, and were, expected in a new product such as this. We are willing to put up with them because the rest of the system offers so much in the way of software construction it leaves most other technologies far behind. What is harder to put up with is re-inventing the wheel. If I have to discover for myself all the issues which were discussed a year ago the productivity gains are lost. I offer these comments as one who has become hooked on Object Oriented programing in general and Eiffel in particular and would hate to see ISE shoot itself in the foot. How many other products have been lost to human-kind through the centuries because the implementation did not live up to the idea and the custommers got tired of waiting . I mean do we really want our grandchildren programming in C++*2 :-) . Frank Caggiano -- Frank Caggiano INTERNET: fcaggian@kepler.com Kepler Financial Management, Ltd. UUCP: ..!uunet!kepler1!fcaggian 100 North Country Rd. fax: (516) 751-8678 Sekauket, NY 11733 voice: (516) 689-6300