HDTenEightyP/NetNews huggingface dataset:
From: weh@abasin.dr.att.com (William E. Hopkins)
Newsgroups: comp.object,comp.specification
Subject: Re: Current OOA/OOD and formal methods
Keywords: A++, Z, VDM, formal methods, OOA/OOD
Date: 31 Jul 92 21:27:51 GMT
Reply-To: william.e.hopkins@att.com
Organization: AT&T Bell Laboratories

In article <1992Jul31.173203.9886@nntpd.lkg.dec.com>, feldman@toklas.enet.dec.com (Gary Feldman) writes:
> 
> Dare I ask what the two [A++] papers were, and where are they available?
> 
>    Gary

The references to the papers and a means to obtain them is in the reply
that was sent to my original request.

From: elkassas@eb.ele.tue.nl (sherif el kassas)
Subject: Re: Found references to A++
Date: Tue, 28 Jul 92 11:22:34 EET

You ( William E. Hopkins ) write:
> 
> I was able to find two references to what is known as Annotated C++ or A++
> (``Annotated C++'' made electronic searches match on every reference to the
> ARM, which is practically *all* C++ papers/books written since 1990...):
> 
> Cline, M., and Lea, D., ``Using Annotated C++,'' C++ at Work, Secaucus, NJ,
> September 1990, p. 65.
> 
> Cline, M., and D. Lea, ``The Behavior of C++ Classes,'' Symposium on
> Object-Oriented Programming Emphasizing Practical Applications (SOOPPA),
> Marist College, Poughkeepsie, NY, September 1990, p. 81.
> 
> 
> Unfortunately, those are not the easiest things to obtain (i.e., not in
> AT&T corporate library).  Does anyone know of any other reference (I do
> have librarians trying to get the above)?

I've ftp'd these papers some time ago (don't remember from where, thought).
I could email them to you.. or you could simply ftp them from:
ftp.eb.ele.tue.nl as pub/docs/c++/A++.tar.Z

Hope this is useful,
Sherif

------------------------------------------------------------------------------
Bill Hopkins          AT&T Bell Laboratories       william.e.hopkins@att.com
Xref: sparky comp.object:3077 comp.lang.eiffel:1029
From: bertrand@eiffel.com (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Intro. book on Eiffel Programming...?
Date: 29 Jul 92 17:08:57 GMT
Organization: Interactive Software Engineering, Santa Barbara CA

From <GEOFF.92Jul28092531@wodehouse.flash.bellcore.com>
by geoff@flash.bellcore.com (Geoffrey Clemm):

>>    I've also
>>    heard a rumor that _OOSC II_ is actively in the works. Anyone care to
>>    confirm or deny?
> 
> [...] The problem is that
> although most of the changes needed for OOSC are trivial, there are a
> few sections which could do with a significant upgrade.
> My guess is that Bertrand can't
> bring himself to just upgrade the sample programs in OOSC from 2.3 to 3.0
> without also changing the sections that would involve more work.

Yes, there will be a second edition sometime, and, yes, it will involve
more than upgrading the Eiffel examples. (I did that at some point and
it took me about two hours for the entire book.) In addition, I can
reasonably commit to ensuring publication in the 20th century.
To say anything else would be rather foolish.

I have found that revising an existing book is harder than writing
a new one. Part of the problem is the maintainability issue which
we all know in its application to software, but which no one has
apparently solved for books. I don't know how to write a book the way one
writes an Eiffel system (out of modular, decentralized components,
meant for reusability and extendibility). Instead a book's
structure is a strict top-down functional decomposition a` la Pascal
(main book, chapters, sections, subsections, paragraphs, sentences,
words), which causes the well-known associated maintainability problems.
(See the book itself for details.) In addition, the structure must be
physically mapped onto fixed-size pages, a pretty harsh requirement.

Adding to the problem are the incredibly positive reactions triggered
by the current edition. (I say this without any arrogance or pretention,
it's just the reality.) This background puts a heavy burden on
the author for the second edition.

Lest anyone think this is all a commercial ploy meant to encourage
people to buy the first edition until the last minute, I won't be
coy about announcing the second edition (on comp.lang.eiffel
in particular) when I send it to the publisher, even if the printing
is still a few months away then. But we are nowhere close to such a
situation.

Thanks for the continued gentle pressure.
-- 
-- Bertrand Meyer
Interactive Software Engineering Inc., Santa Barbara
bertrand@eiffel.com
From: SPARKER@CHL.IE ("Simon Parker, Computer consultant")
Newsgroups: comp.lang.eiffel
Subject: How to design a data structure library
Date: 28 Jul 92 08:19:00 GMT
Organization: University of Wales College of Cardiff, Cardiff, WALES, UK.
X-Envelope-To: comp.lang.eiffel@cm.cf.ac.uk
X-Vms-To: IN%"comp.lang.eiffel@cm.cf.ac.uk"
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway


 [Reference the discussion on data structure library design, specifically
 the question of list cursors]
 
It seems to me that in some circumstances the complexity of managing
multiple cursors for a list might be avoided by using shallow copies.
 
I'm not sure which variant of 'copy' I mean, but it's the one which
produces a new list and a new set of 'linkables' without copying
the contents.
 
Instead of regarding the list as the shared object and the cursors
as private access mechanisms, think of the list elements as shared
and the list itself as a private access mechanism.
 
 
There are a number of advantages of this approach.
 
 One cursor per list will suffice, preserving the elegance of the
 'active structure' concept.
 
 Each accessor has a full set of list features, including count,
 insert, remove.
 
 Interference between multiple inserters and the philosophical questions
 about versions go away. The corollary, of course, is that a new element
 is only visible to the inserter.
 
 Similarly with deletion - the thing the element references doesn't
 get deleted, it just gets detached from the deleter's list. Again,
 it's still in the other lists.
 
 Modification of an object which appears in multiple lists is arbitrated
 by the object, rather than by the lists or cursors.
 
There are of course disadvantages which make the approach unsuitable
in many circumstances. If a shared list is what you need copies won't
help, and I don't see how this could work with expanded types. It
is easy to find situations in which the advantages turn into disadvantages!
 
Does this have merit, or am I being naive?
Newsgroups: comp.lang.eiffel
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: Small methods ! Why ?
Organization: lost in NYC
Date: Wed, 29 Jul 92 12:25:45 GMT

In article <13303@ns-mx.uiowa.edu> rajar@herky.cs.uiowa.edu (Chandrashekar Rajaraman) writes:
>Hi,
>
>I came across the following sentence in a paper:
>
>"Good object oriented programming style seems to encourage the
>use of many small methods."
>
>Why is this so ?
>
>This programming style leads to code (and functionality)
>that is widely dispersed.  Therefore, a maintainer may have to
>use sophisticated class browsers to understand the code even for
>a fairly simple task, simply because it is widely dispersed.
>
>This style seems to be quite prevalent among C++
>programmers.
>
>Is it so with programmers in other OO languages as well ?
>

[...]

It's not just an OO programming style. I have always said that a
PASCAL procedure should _never_ be more than a screenful (I'm talking
about 80 x 24 screens, not those humongous X-stations :-) ).

In OO languages, even a simple task may involve many classes. Trying
to understand the program by following the thread of control can be
difficult. Of course, there is nothing wrong with using browsers - I
wish I had a browser for Modula-2.

I think the key to better understanding of OO programs is to undestand
the individual classes and to worry less about the overall control
flow.

...richie


P.S. A friend, who had to maintain one of my larger Modula-2 programs (over
     20,000 lines of code), said "Where do you do the work in this code?
     Everything is a procedure call!".



-- 
* Richie Bielak   (212)-815-3072   | "Your brain is a liquid-cooled parallel  *
* Internet:       richieb@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan."                       *
*    - Strictly my opinions -      |                     - David Chudnovsky - *
Newsgroups: comp.lang.eiffel
From: mork@yoyo.cc.monash.edu.au (Simon Raik)
Subject: Eiffel/s
Keywords: eiffel
Organization: Monash University, Melb., Australia.
Date: Wed, 22 Jul 1992 07:14:40 GMT

Has anybody used Eiffel/s? I want to write a system for the ibm and
would like to do so in Eiffel. This is all I could get my hands on.

It looks a little incomplete...can anyone comment on this.

Cheers,
Simon Raik.
simonr@bruce.cs.monash.edu.au
Newsgroups: comp.lang.eiffel
From: rajar@herky.cs.uiowa.edu (Chandrashekar Rajaraman)
Newsgroups: comp.lang.eiffel
Subject: Small methods ! Why ?
Date: 28 Jul 92 08:02:08 GMT

Hi,

I came across the following sentence in a paper:

"Good object oriented programming style seems to encourage the
use of many small methods."

Why is this so ?

This programming style leads to code (and functionality)
that is widely dispersed.  Therefore, a maintainer may have to
use sophisticated class browsers to understand the code even for
a fairly simple task, simply because it is widely dispersed.

This style seems to be quite prevalent among C++
programmers.

Is it so with programmers in other OO languages as well ?

Send replies to me.

Thanks.

Chandra
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.lang.eiffel
Subject: Hypertext (was Re: Intro. book on Eiffel Programming...?)
Date: 30 Jul 92 07:59:22 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK

In article <107@eiffel.eiffel.com> bertrand@eiffel.com (Bertrand Meyer) writes:

>I don't know how to write a book the way one writes an Eiffel system
>(out of modular, decentralized components, meant for reusability and
>extendibility).

I do.  Its called `hypertext'.

For more information, see Ted Nelson's book `Dream Machines'.

What we don't have at the moment is a real hypertext authoring system
(yes, I know about Hypercard et al, but there is nothing widespread
enough to replace paper books).

Paul.
-- 
Paul Johnson (paj@gec-mrc.co.uk).	    | Tel: +44 245 73331 ext 3245
--------------------------------------------+----------------------------------
These ideas and others like them can be had | GEC-Marconi Research is not
for $0.02 each from any reputable idealist. | responsible for my opinions
From: tynor@hydra.gatech.edu (STEVE TYNOR)
Newsgroups: comp.lang.eiffel
Subject: Re: Intro. book on Eiffel Programming...?
Date: 24 Jul 92 17:33:25 GMT
Organization: Georgia Tech Research Institute
In-reply-to: nagle@netcom.com's message of 24 Jul 92 16:06:29 GMT

In article <pyhmn2d.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:

|         Remember, programming in Eiffel is supposed to be HARD.  You have
| to SUFFER for your art.  Eiffel is in the grand tradition of the the Hoare
| "programming is not for everyone" school.

Yikes! That's certainly not my experience. Programming in Eiffel is
relatively easy. It has a very elegant design that lets one concentrate
on design and implementation without worrying about bizzare quirks in
syntax or semantics. I suspect you're confusing the language with the
book ("Eiffel: The Language" (ETL) (or you are just egging us on :-) )).

| The formalism is not to be
| avoided, but studied with dedication until it is mastered.  One can no

It's true that ETL is somewhat heavy on formal definition of the
language and its semantics, but I consider that to be a `good thing'
(it's the official language definition after all). It certainly reduces
amiguity and makes it easier to understand exactly what the language
requires and guarantees. 

I do, however, agree that it can take some effort for the casual
programmer to wade through the formalisms -- The Eiffel community really
needs a companion book ("Eiffel Primer"?) that is more accessible, not
so formal and includes lots of examples (hint, hint!).

| more program properly without mastery of the formal approach than one can
| do physics without calculus.
| 
|         If you want OOP the easy way, use Smalltalk.

Smalltalk is nice too, but I'll take Eiffel any day. Especially if I'm
concerned about maintanence and multi-programmer projects. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
C++: Just say no.
                     
    Steve Tynor
    Georgia Tech Research Institute
    tynor@prism.gatech.edu
From: mod@cs.man.ac.uk (Michael O'Docherty (CAG ra))
Newsgroups: comp.lang.eiffel
Subject: Type hole in Eiffel
Date: 29 Jul 92 15:49:49 GMT

Please consider the following system of classes, which runs up against
a type hole in Eiffel 2.3:

---------------------------------------------
class CELL[T]
export
        item, put
feature
        item:T;
 
        put (v:like item) is
                do
                        item := v
                end;

end
---------------------------------------------
class PARENT
feature
end
---------------------------------------------
class CHILD
export
    child_routine
inherit
    PARENT
feature
    child_routine is
        do
        end;
end
---------------------------------------------
class SILLY
feature
    fill_with_parent(p_cell:CELL[PARENT]) is
        local
            p:PARENT;
        do
            p.Create;
            p_cell.put(p);
        end;

    Create is
        local
            c_cell:CELL[CHILD];
        do
            c_cell.Create;
            fill_with_parent(c_cell);
            c_cell.item.child_routine;
        end;
end
---------------------------------------------

The problem stems from the fact that CELL[CHILD] conforms to
CELL[PARENT]. If you follow through the Create procedure of SILLY
you'll see that `child_proc' is called on an object whose dynamic type
is PARENT. This causes 2.3 to seg-fault at run time. I tried a similar
but more convoluted example of this on EIffel/S for the PC (note that
this is 3.0) and the error was *caught* at run time and a message
issued along the lines of ``feature not on object''.

I know this is probably an old and very well known hole, (I believe
it's the second one outlined in ``A Proposal for Making Eiffel
Type-Safe'', W.R. Cook, Computer Journal, August 1989). However, there
are a few questions which I have difficulty finding answers to in the
FAQ and the Eiffel 3.0 book (either because I'm missing something or
because they're not there ;^) :

 (1) Are all the classes class-valid?
 (2) Is the system system-valid?
 (3) Is this hole caught by ISE Eiffel 3.0 (salivates uncontollably),
        and if so is it caught at compile time or run time?
 (4) Alternatively to (3), have the conformance rules been changed to
        ban this situation?
 (5) Does ISE Eiffel 3.0 enforce every aspect of system and class
        validity (and if so, at run time or compile time)?
 (7) Any other questions I haven't thought of?
 (6) Is that enough questions?


Any attempts to answer any or all of these questions greatly appreciated.

Mike.

Internet: mod@cs.man.ac.uk, wet string: (+44) 061 223 1301 ext. 2343
From: ian (Ian Cottam)
Newsgroups: comp.lang.eiffel
Subject: Eiffel on UNIX
Date: 28 Jul 92 16:16:17 GMT
Reply-To: ian@cs.man.ac.uk (Ian Cottam)

Will ISE Eiffel 3 still use the UNIX sbrk call for some memory
management?  Given that many library functions use malloc
(even fprintf on the SUNs I belive), should not sbrk be reserved
for the implementors of (alternative) mallocs?
-- 
Ian Cottam, Room IT209, Department of Computer Science,
University of Manchester, Oxford Road, Manchester, M13 9PL, U.K.
TEL (+44) 61-275 6157 FAX (+44) 61-275-6236 EMAIL ian@cs.man.ac.uk
From: 88600044s@csghsg5a.bitnet
Newsgroups: comp.lang.eiffel
Subject: Eiffel for Windows or OS/2 ?
Date: 22 Jul 92 08:43:56 GMT
Organization: University of St.Gallen, Switzerland

I'd like to have alook at Eiffel but cannot afford UNIX. For some time
ago there were rumours about an Eiffel implementation for Windows.
Then there is Eiffel/S for DOS and OS/2. Unfortunately, it does only
have a compiler but no library. (They said the library is shipping in
about two years...)

I wonder over and over again that so many people believe object-
oriented programming needs nothing but the appropriate o-o compiler
and thats it. This seems not only to be a habit of C++ enthusiasts.

There have been some topics arguing that Eiffel does not do very well
compared to Smalltalk or C++. The reason is not simply marketing
(this seems to be the all American explanation if sales for a product are 
weak) but the fact that there is no Eiffel library around for Windows and 
OS/2. Because that's were the masses are - not in UNIX. And these 
masses have been absorbed for good reasons by Digitalk's Smalltalk
of which the o-o library is excellent.

So does anybody know of an Eiffel programming environment for 
Windows or OS/2 (that is including library)?

Many thanks for any hint,
Olli Plohmann
From: pej@richsun.cpg.trs.reuters.com (Paul Jatkowski)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel on UNIX
Date: 30 Jul 92 19:22:45 GMT
Reply-To: pej@richsun.cpg.trs.reuters.com (Paul Jatkowski)
Organization: REUTERS Client Site Systems

In article <5496@m1.cs.man.ac.uk>, ian (Ian Cottam) writes:
|> Will ISE Eiffel 3 still use the UNIX sbrk call for some memory
|> management?  Given that many library functions use malloc
|> (even fprintf on the SUNs I belive), should not sbrk be reserved
|> for the implementors of (alternative) mallocs?

In the current release you can #define XENIX in _internal.c and
recompile the run time
library.  Malloc makes a number of assumptions that are not true a
program does an sbrk
after it's first malloc. The core files are *interesting*

Paul Jatkowski
Reuters
From: bertrand@eiffel.com (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Intro. book on Eiffel Programming...?
Date: 28 Jul 92 15:58:03 GMT
Organization: Interactive Software Engineering, Santa Barbara CA


It is true that (to my knowledge) the only published books available
on Eiffel so far are by me. However:

1. Many universities around the world teach Eiffel and a number
of professors have developed fairly extensive course notes in various
languages.

2. In terms of books proper, I know of about half a dozen projects
of Eiffel books. Some of them have come my way in my capacity as editor
of the Prentice Hall Object-Oriented Series (by the way, to add a sneaky
commercial pitch, I am always interested in more good proposals); others
are for other publishers. I can see at least two books out before the
end of the year, and others to follow shortly.

Thanks, by the way, for the nice comments about my own books. Their
deficiencies are obvious too, so their existence should not discourage
others.
-- 
-- Bertrand Meyer
Interactive Software Engineering Inc., Santa Barbara
bertrand@eiffel.com
From: Ted.W.Lawson@cm.cf.ac.uk (Ted Lawson)
Newsgroups: comp.lang.eiffel
Subject: Re: Intro. book on Eiffel Programming...?
Date: 25 Jul 92 13:03:10 GMT
Organization: University of Wales College of Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

In article <pyhmn2d.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
|cwt26780@uxa.cso.uiuc.edu (Conrad W Taylor) writes:
|>         I'm looking for an introductory book on Eiffel programming that in-
|>cludes a great deal of examples.

etc, etc....

|        Bertram Meyer's books are all there are, apparently.  There are three
|of them (on design, the language, and the library) and each uses a different
|version of Eiffel.  This, of course, will not bother the serious student.
|
|        Remember, programming in Eiffel is supposed to be HARD.  You have
|to SUFFER for your art.

etc, etc.....
|					John Nagle


	I think this is meant to be a little joke. Just in case it is not
	let me say that over the past two years I have supervised about
	half a dozen students at final year or masters level all of whom
	have successfully and enjoyably completed practical programming
	projects in Eiffel using for guidance nothing more than
	"Object-Oriented Software Construction" and the ISE library source
	code and documentation.  The projects were all of roughly 2
	man-months duration. In several cases the student had no prior
	knowledge of object-orientation whatsoever.

	It certainly would be nice if there were a few more text books
	on Eiffel.  The reason there are not is perhaps because Bertrand
	Meyer's books are so well-written. Anyone contemplating writing an
	alternative has a hard act to follow.

	This situation is in contrast to that of another well-known O-O
	language where the seminal text book was a mess and so its
	appearance was quickly followed by books from other authors who
	knew they could do better.

Ted Lawson
Newsgroups: comp.lang.eiffel
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Intro. book on Eiffel Programming...?
Organization: Bellcore
	<1992Jul27.150245.8716@merlin.hgc.edu>
Date: 28 Jul 92 09:25:31

In article <1992Jul27.150245.8716@merlin.hgc.edu> jcm@hgc.edu (James McKim) writes:
   I've also
   heard a rumor that _OOSC II_ is actively in the works. Anyone care to
   confirm or deny?

Meyer explicitly denied this a month or two back.  The problem is that
although most of the changes needed for OOSC are trivial, there are a
few sections which could do with a significant upgrade.
My guess is that Bertrand can't
bring himself to just upgrade the sample programs in OOSC from 2.3 to 3.0
without also changing the sections that would involve more work.

Cheers,

Geoff
--
geoff@bellcore.com
From: nagle@netcom.com (John Nagle)
Newsgroups: comp.lang.eiffel
Subject: Re: Intro. book on Eiffel Programming...?
Date: 24 Jul 92 16:06:29 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

cwt26780@uxa.cso.uiuc.edu (Conrad W Taylor) writes:
>         I'm looking for an introductory book on Eiffel programming that in-
>cludes a great deal of examples.  The only source that I have at this time is
>Eiffel: The Language which is more of a reference for the language instead of
>an introductory book on programming in Eiffel.  If anyone knows of such a text
>, please e-mail me at ctaylor@ncsa.uiuc.edu or cwt26780@uxa.cso.uiuc.edu.

        Bertram Meyer's books are all there are, apparently.  There are three
of them (on design, the language, and the library) and each uses a different
version of Eiffel.  This, of course, will not bother the serious student.

        Remember, programming in Eiffel is supposed to be HARD.  You have
to SUFFER for your art.  Eiffel is in the grand tradition of the the Hoare
"programming is not for everyone" school.  The formalism is not to be
avoided, but studied with dedication until it is mastered.  One can no
more program properly without mastery of the formal approach than one can
do physics without calculus.

        If you want OOP the easy way, use Smalltalk.

					John Nagle
Newsgroups: comp.lang.eiffel