HDTenEightyP/NetNews huggingface dataset:
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.lang.eiffel
Subject: Re: Small methods ! Why ?
Date: 29 Jul 92 07:31:28 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK


>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 ?

One of the major goals of OO programming is flexibility.  A big
function can only be modified by delving deep into its code.  The only
way of reusing a part of its functionality is by copying the code and
changing bits.  On the other hand, lots of little functions can be
modified by replacing one function with another.  Dynamic binding
(what C++ calls `virtual functions) provides a way of doing this in a
controlled manner.  Hence an OO program with lots of little functions
is more flexible and hence more mainainable.

>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.

One of the major concepts in Eiffel is that you should not have to
delve into the code to understand a piece of functionality.  The class
documentation (including the short-flat form with its preconditions
and postconditions) should make this clear.

If it does become necessary to delve into a function, one that has a few
lines of code which call other functions is more understandable than a
complex mess of loops and local variables.

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

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

Yes.  Even more so with Eiffel.

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: cwt26780@uxa.cso.uiuc.edu (Conrad W Taylor)
Subject: Intro. book on Eiffel Programming...?
Organization: University of Illinois at Urbana
Date: Wed, 22 Jul 1992 16:11:18 GMT

         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.

Thanks in advance,

-Conrad
From: tob@world.std.com (Tom O Breton)
Newsgroups: comp.lang.eiffel
Subject: Does this group have a FAQ file?
Date: 21 Jul 92 20:20:53 GMT
Organization: The World Public Access UNIX, Brookline, MA

I've heard quite a bit about Eiffel lately, and it's definitely piqued my     
curiosity. I scanned the back messages for a FAQ file or a ftp address for one
and didn't see any. Could someone please tell me where to find one?           

	Tom
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.lang.eiffel
Subject: Re: How to design a data structure library
Date: 30 Jul 92 08:41:42 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK

In article <1C20AE2393DF002118@chl.ie> SPARKER@CHL.IE ("Simon Parker, Computer consultant") writes:

>It seems to me that in some circumstances the complexity of managing
>multiple cursors for a list might be avoided by using shallow copies.

[ie the default behaviour of `copy' on a linked list]

>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.

[...]

> 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 questions are not just philosophical.  For instance, suppose I
insert an element into such a shared list.  The `count' of one LIST
object gets updated but the other does not.  If I now iterate through
the list using the other LIST object I will eventually have
(position>count+1), which violates the invariant of the LIST.

> The corollary, of course, is that a new element is only visible to
> the inserter.

I don't understand.  If I insert an element into the middle of a
shared list, how can it not be visible to all the other objects which
share that list?

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: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Intro. book on Eiffel Programming...?
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 29 Jul 1992 02:33:13 GMT

nagle@netcom.com (John Nagle) writes:

>        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.

I think there is a demand for a simple book on Eiffel version 3, so
that people can get started. Eiffel is simple enough that this need
take no more than 100 pages, and I think it will cover most of the
language.

As for programming in Eiffel being hard, and having to suffer for your
art, try 'gs/Eiffel/C++/' in the above, and I think that is closer to
the truth. "Eiffel:The Language" is a relatively pleasant book to
read, and it is designed so you can skip over large bits you don't
need to get started. Try reading the C++ ARM though, ugh! But then it
is my observation that there are no shortage of books trying to
explain the ins and outs and whys and wherefores of C++. The complexity
of C++ must be a publishers dream come true!
-- 
Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Newsgroups: comp.lang.eiffel,comp.lang.c++,comp.std.c++,comp.object,comp.software-eng
From: skalyan@mars.cs.clemson.edu (R. Kalyan Sundhar)
Subject: Final tally on usage of OO Methodologies
Organization: Clemson University Computer Science Dept.
Date: Mon, 27 Jul 1992 14:18:02 GMT

Hi,

Here is the final tally on the usage of OO methodologies.

	Shlaer	       15 	
	Rumbaugh       14	
	Coad	       11	
	Booch		6
	WirfsBrock	2
	SOOM		1
	Texel		1

	------------------
	Total	       50
	------------------

In case you have [or know of someone who has] not responded
to this survey, please contact me by email.

Thanks for your time.
Kalyan
Newsgroups: comp.lang.eiffel
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Small methods ! Why ?
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 29 Jul 1992 02:53:51 GMT

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 sounds like a typical system written in C, where you have
100s of files to maintain, and the thing becomes a nightmare.
It is true that analagously, lots of little methods will eventually
become a maintenance problem. But I think this is counteracted
by dividing the system into the larger class chunks. However,
on the understandability and maintainability side, large routines
are usually not understandable or maintainable. So breaking them
down into smaller chunks with good clean interfaces between them
will balance this problem.

Another reason why you would want to break routines into smaller
chunks is that it helps reusability. If you put more than one
logical step into a routine, and you want to change one part
of the functionality, you will have to override the whole lot.
An example will make this clear.

class A

    routine f
       seq1;
       seq2;
    end f;
end A

seq1, and seq2 are actually large sequences of program source.  Now if
you design a class B that inherits from A, you might find you have to
modify the behaviour of the routine f in some way.  On examination, you
find that the functionality of the first part of f, ie seq1, is fine.  But
you need to change seq2. Now what you have to do is to rewrite the whole
of seq1 in your redefinition of the f routine.

Class A would have much better been written:

class A

   routine f1
      seq1;
   end f1;

   routine f2
      seq2;
   end f2;
end A

This way, f1 would have been completely reusable as it was, and the 
redefinition in your new B class would have been localised to f2. 


     

-- 
Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Newsgroups: comp.lang.eiffel
From: bytor@grumpy.bellcore.com (Ross Huitt)
Subject: Re: Small methods ! Why ?
Organization: Bellcore
Date: Tue, 28 Jul 92 14:51:26 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."

(Was this from one of my papers? Sounds familiar...)

|> 
|> Why is this so ?

There are several different reasons. 'get' and 'set'  methods are typically one-liners,
delegation of a message to a component is also a one-liner. These things add up. (Or don't
add up...)

|> 
|> 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 ?

I have similar numbers for smalltalk as well. I've casually looked at some other
OO languages and they appear to follow the same trend.

It appears to be more a function of how OO the code actually is than the language. A system
that is designed and implemented in an OO fashion will (apparently) have far fewer
statements-per-method than a system that is design and implemented using 'conventional'
techniques.

|> 
|> Send replies to me.
|> 
|> Thanks.
|> 
|> Chandra


Ross Huitt
bytor@ctt.bellcore.com
From: mikeh@kralizec.zeta.org.au (Michael Hore)
Newsgroups: comp.lang.forth
Subject: Re: OOP Implementation Details
Date: 24 Jul 92 09:36:48 GMT
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32


Antero Taivalsaari writes:

> All the schemes work, so the difference between them is mainly 
> that of readability and personal preference.

I agree completely, which is one reason I haven't come back into
this discussion.  (The other is I haven't had time :-)  )

Mops can handle message paths, along the lines

msg1: obj1  msg2: []  msg3: []

Of course, if the recipient of msg2 needs parameters, they would
need to be set up right at the start, or else you could do

msg1: obj1  parmx parmy rot  msg2: []  etc.

Not so nice -- clumsy even, but not at all common, IMHO.  By far
the most common is the simple  msg: obj, which I find very readable.
But I do agree that this is personal preference, and I have no
strong objections to any of the other ideas presented here.  My
priority now is to make my implementation as good as I can, and add
tools, using the syntax I have already.

Bob Loewenstein asks, rhetorically:

> Is it a Forth that is object oriented in ways, or is it
> a different language implemented in Forth.

My feeling about Neon/Yerk/Mops is that it is (they are?)
an OOP extension of Forth.  I know Chuck Duff (the creator
of Neon) described it as a new language, and I can see
that point of view too.  Again it's a personal thing I guess,
but since it's in the nature of Forth to be extensible, and
N/Y/M supports normal Forth code with one exception, I prefer
to call it a Forth.

The one exception is that words ending in colon are reserved
as messages -- they can't be anything else.  I don't feel this
is a strong disqualification.  I'd like to make Mops ANSI-compliant,
and feel I can do it with a relatively short prologue, WITH just
that one exception.  I guess then it wouldn't really be compliant,
just almost so.

--  Mike.     
------------------------------------------------------------------------
Mike Hore          internet:    mikeh@kralizec.zeta.org.au
"Wisdom has never been known to enter the head through an open mouth"
-- overheard somewhere.
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: ANS figFORTH
Keywords: ANS, fig, implementation
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 21 Jul 1992 08:17:30 GMT

In article <l6lr0pINNsvk@appserv.Eng.Sun.COM>, wmb@pi.Eng.Sun.COM (Mitch Bradley) writes:
|> 
|> > We'll hope to get volunteers to join the group, so that we'll get not just
|> > another Forth, but THE Forth of the 90th!
|> 
|> ... thus further eroding the ability of Forth vendors to make a profit,
|> thus ensuring that Forth will forever be relegated to a hobbyist language
|> or an academic curiosity.
|> 
|> Down with free Forth systems.

Could you present evidence for your premise that commercial success of
a language comes from vendor profit?

Looking at the languages currently in commercial use, I see that it's
the other way round: first the language became popular (usually in
academia), then it became commercially used and then vendors could
make a profit (in spite of free or low-cost academic and hobbyist
implementations).  This is true for Pascal, C, and in some sense also
for FORTRAN.

As a counterexample look at Eiffel and Miranda, two no-freebie,
vendor-profit languages. Eiffel sure is the better language, but C++,
which has free implementations, is taking over. Miranda has some
academic popularity, but ML (a similar language with a high-quality,
free implementation) is used more widely.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Newsgroups: comp.lang.forth
From: bj608@cleveland.Freenet.Edu (Robert S. Williams)
Subject: UTIL FORTH on a Palmtop PC
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)
Date: Tue, 28 Jul 92 06:53:54 GMT


I have recently bought Uri Thiers' extension of fORTH-83 for the 
Hewlett Packard 95LX palmtop. I was wondering if there might 
not be a repository of Forth-83 source for various applications 
that I might look at via FTP.
Any hints/tips/suggestions?

                             Robert S. Williams
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: X3J14 Holding Pattern Here
Date: 21 Jul 92 12:27:25 GMT
Organization: EIEI-U

Category 10,  Topic 12
Message 189       Tue Jul 21, 1992
B-LEE [b0b]                  at 03:19 EDT
Path: b0b
 Newsgroups: Category.10
 Subject: Re: Fixing the Standards - WHY??
 From: b0b@interface.via.mind.org (Bob Lee)
 Message-ID: <mau8NB2w165w@interface.via.mind.org>
 Date: Mon, 20 Jul 92 08:02:22 PDT
 Organization: Interface BBS, 707-544-9661, ForthNet

 bigras@mala.bc.ca writes:

 # I have beem using Forth for 10 years and all through that time there
 # have been these people trying to fix the standard.  They do some good
 # by expanding the distribution of information on various
 # implementation techniques.  By and large though there efforts are {
 # Properly } ignored by most Forth users.  What is so good about Forth
 # is its very small kernal and infinite extensibility, and
 # interactivity.  This makes Forth ideal for imbedded systems of all
 # kinds, including embedding the Forth in an application.  This 
 # compactness and total flexibility and control are not available
 # outside of assembly language.  This flexibility extends to the entire
 # development system as well. 

    The Forth-83 Standard, with all its faults, gave me a point of 
 reference when exploring a new implementation of Forth.  I knew that I 
 could count on certain behaviors.  ANSI Forth provides a similar point of 
 reference, but goes considerably further and is much more coherent.

    I'm not happy with every aspect of ANSI Forth, and I doubt that anyone 
 is.  But it's "way better" than anything that's gone before, and nobody 
 is required by law to implement it.  Most "Forth-83" implementations 
 deviate considerably from that standard, and I expect there will be 
 considerable deviation in ANSI Forth implementations.

 # I am currently bringing up Forth for OS/2 2.0 and the kernal so far is
 # 10K.  No I have not implemented every word that somebody wants to
 # stick in a standard.  Any words that are wanted can be added by
 # whomever needs them.  All my words are vectored as well so if you
 # like flavour X just change it.

    As it ever shall be!  The ability to change the language to suit the 
 job is Forth's strongest feature.  An ANSI Forth implementation needn't 
 take away that feature.  People are concerned that ANSI Forth won't 
 "allow" them to do low level tricks.  That's just silliness - a "Standard 
 Program" can't do certain things, but few of us write "Standard Programs" 
 anyway.  The same is true in the C community, btw.

 # If you want real standards { and your hands tied } feel free to use C
 # or Ada or Pascal.
 # 
 # As far as calling experimental varients Forth goes ... that is what
 # Forth is all about.  You standards types can feel free to go find 
 # another name! 
 # 
 # 
 # Tony Bigras
 # 
 # ok

    Your "ok" tag made my day, Tony.  Thanks for writing!

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for ROMability
Date: 21 Jul 92 12:27:29 GMT
Organization: EIEI-U

Category 10,  Topic 22
Message 67        Tue Jul 21, 1992
B.RODRIGUEZ2 [Brad]          at 01:06 EDT
 
Elizabeth:  I'm quite confident that a cross-compiler can handle _some_ ANS
Forth programs.  I'm worried that no cross-compiler will be able to handle
_all_ ANS Forth Standard Programs.  (So much for portability.)

Len:  This upsets me because I write cross-compilers.  The example I'm having
trouble with is ENVIRONMENT?, which can't be used portably under a cross-
compiler.  It seems the majority of the TC doesn't care.  I will heed your
advice and phrase my request for clarification carefully; since ANSI is
presumably reviewing this correspondence, I trust that my questions will be
answered informatively.

Elizabeth and Len: re. accepting an imperfect standard, and fixing it later,
my experience is that a) the "fixing" process almost never happens, and b) if
it does, the troublesome practices have established so much inertia that they
can't be changed.  You say, better a bad standard than no standard.  I
disagree.

Dennis: I'm not worried about cross-compilers producing an ANS Standard
System; I'm worried about cross-compilers accepting ANS Standard Programs. 
Cross-compilers (as opposed to metacompilers) are hardly "unique" to Forth,
and they are the sine qua non of embedded systems programming.  Look at any
issue of ESP magazine.

Brad Rodriguez
 B.RODRIGUEZ2 on GEnie   |   bradford@maccs.dcss.mcmaster.ca
 Meskimen's Law:  There's never time to do it right, but there's always time
to do it over.
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Mops
Date: 21 Jul 92 12:27:21 GMT
Organization: EIEI-U

Category 7,  Topic 40
Message 19        Tue Jul 21, 1992
M.HORE [Mike]                at 06:17 EDT
 
  There is a possibility that Mops 2.2 may not run off a floppy. It seems to
work on my system, but there is a loophole which may cause trouble on some
systems.

(This just applies to Mops itself, not to installed applications which should
be OK).

If this happens to you, you can fix it with a change to the word RUN in the
file Frontend, in the folder "System source".  The new version of RUN is:

 : RUN   0 -> pause  sysinit  load: windowMod  run_FE
     ['] (pause) -> pause  ;

You then need to recompile the system above the nucleus, according to the
instructions in my previous posting.

BTW, in future releases of Mops I may not include all the binaries in the
release, to save download time, since the package is now so big.  In other
words, the procedure for compiling the system above the nucleus will probably
become the normal practice.  It's not hard to do (I hope you all agree!!)

Cheers,   Mike.
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: +LOOP in the Standard
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Wed, 22 Jul 1992 08:07:02 GMT

In article <l6lr51INNsvo@appserv.Eng.Sun.COM>, wmb@pi.Eng.Sun.COM (Mitch Bradley) writes:
|> 
|> > As it reads in Basis 15,
|> > 	2 0 DO 1 +LOOP
|> > will loop twice, but
|> > 	-2 0 DO -1 +LOOP
|> > will loop three times.
|> > 
|> > Is this in the current dpANS and is this intended?
|> 
|> Yes, and it's the way that Forth systems have always worked.

Thanks for the reply.

I have tested it on two systems, TILE Release 2.1 (which claims to be
a Forth-83) and a fig-Forth derived system that claims to be a
Forth-79. On both systems both loops loop two times.

Also, the fig-Forth installation manual defines this as the fig-Forth
behaviour. Zech's Forth book (the one I learned Forth with) teaches
this symmetric behaviour.

So, you (the ANSI team) should add a big warning to the description of
+LOOP, making implementors aware of the problem and the ANSI
conforming behaviour, advising porters to check their +LOOPs and
perhaps advising users not to use negative increments.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen