HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: Class methods (was: Re: How to design a data structure library)
From: <MKK2@psuvm.psu.edu>
Date: Tue, 28 Jul 1992 12:58:46 EDT
 92Jul27100601@wodehouse.flash.bellcore.com> <graham.712278529@galois>
Organization: Penn State University

In article <graham.712278529@galois>, graham@maths.su.oz.au (Graham Matthews)
says:

>Personally I think this is just awful. I want to write

>        c := a + b;             OR
>        c := a union b;

>Any other notation is completely non-suggestive.

If you are saying that the OOPL language must support operator overloading
to be useful then I guess you'll just have to use C++ or some such.

   In principle, I agree.  c := a + b translates into English  for me
as something like "start with a, perform the union operation on it with
b as an argument, return the union as a result, and assign it to c."

While your crystal clear traditional syntax is nice, I feel fine with

   c = [a union:b];

As for using Class methods, I wouldn't mind if there was also a

   c = [Set union:a :b];

method.
Newsgroups: comp.object
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: Is GC needed?
Organization: NY NY
Date: Tue, 28 Jul 92 12:02:04 GMT

In article <1992Jul27.074159.10951@ugle.unit.no> sebra@idt.unit.no (Svein Erik Bratsberg) writes:
>In article <AXEL.92Jul24154632@avalanche.cs.tu-berlin.de>, axel@cs.tu-berlin.de (Axel Mahler) writes:
>|> Have there been any attempts to employ multi-processor shared-memory
>|> computer architectures for solving the GC problem ? Why not have a 
>|> dedicated GC processor that frees the application from worrying about
>|> memory management ? I've not given the idea a great deal of thought, so
>|> it might actually be stupid or unfeasible. Comments ?
>|> 
>|> Axel.
>
>Here's an old reference:
>
>Guy L. Steele Jr., "Multiprocessing Compactifying Garbage Collection",
>Communications of the ACM, 18(9), Sept. 1975, Pages 495--508.
>1975 ACM Student Award, Paper: First Place.
>

Here is another. This paper was presented at OOPSLA '91.


   Sharma R., Soffa M., "Parallel Generational Garbage Collection",
   Conference Proceedings OOPSLA '91, pp: 16-32.


...richie


-- 
* 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.object
From: dlw@odi.com (Dan Weinreb)
Subject: Re: A question of notation
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Date: Thu, 23 Jul 92 14:49:37 GMT

In article <MOSS.92Jul22103537@ibis.cs.umass.edu> moss@cs.umass.edu (Eliot Moss) writes:

   An additional remark I would make is that there is no "standard" about this at
   all. Trellis does it the M (O ...) way (kind of following CLU syntax),
   Modula-3 does it the O.M way, and Smalltalk does it O M with arguments, if
   any, mixed in with the method name. Syntax can be relevant to readability,
   writablity, and software engineering concerns deriving from them, but there
   are no semantic power or expressiveness reasons to prefer one of these forms
   over another.

I agree and I'd like to add a footnote.

In Lisp-with-Flavors (or Lisp-with-CLOS), the language both has the
concept of "function call" and "message send".  The main difference
between Old Flavors and New Flavors was to go to a syntax in which a
"message send" looks syntactically like a function call.

A typical Old Flavors "message send": (send my-window :refresh)
A typical New Flavors "message send": (refresh my-window)

We considered it a big advantage to use the same syntax for both
ordinary functions and "message sending", for several reasons.

The main reason was modularity.  The idea is that from the point of
view of the caller, "refresh" is an operation with a certain contract.
Whether "refresh" implements that contract by using an automatic type
dispatch or not is an internal implementation issue that should not be
reflected in the advertised interface.

Secondary reasons were so that "message send" operations could be
treated as "funargs" in a uniform way, and things like that.

CLOS is like New Flavors in this respect.  C++ is analogous to Old
Flavors in this respect.

In languages with no special distinction between "function call" and
"message send" (e.g. Smalltalk), of course, this issue does not arise.
Newsgroups: comp.object
From: hall@dec254.uucp (Phil Hall)
Subject: Re: A question of notation
Organization: Cincinnati-Milacron, Inc.
Date: Thu, 23 Jul 92 18:29:29 GMT


<MOSS.92Jul22103537@ibis.cs.umass.edu> Eliot Moss writes:

> The difference between O.M (arg1 ... argN) and M (O, arg1 ... argN) is clearly
> only a question of syntax, since one can readily change one abstract syntax
> tree into the other. I suppose there might be occasions where one form would
> require parentheses around O and the other would not, but that's a question fo
> concrete syntax, and again not semantics.
> 
> An additional remark I would make is that there is no "standard" about this at
> all. Trellis does it the M (O ...) way (kind of following CLU syntax),
> Modula-3 does it the O.M way, and Smalltalk does it O M with arguments, if
> any, mixed in with the method name. Syntax can be relevant to readability,
> writablity, and software engineering concerns deriving from them, but there

  [semantic equality conclusion omitted]

I might add some comments about these concerns.  While the difference between
O.M (...) and M (O ...) is really only syntactic, in practicality, the
two notations often have very different interpretations.

The O.M (...) notation obviously distinguishes the object O.  This form 
clearly implies that the method M must belong to the class or subclass of 
O.  This is quite different from just passing O as an argument, which
does not suggest M associates with any class at all (at least not in
a class definition).

This distinction seems to be pretty significant in a persons perception 
of what object-oriented-ness is.  It is for me. 

> 
>		J. Eliot B. Moss, Associate Professor

Phil
-------------
Philip W. Hall                    Internet:  hallpwcd@ucunix.san.uc.edu
Cincinnati Milacron, Dept. 82G               
Advanced Systems Division
4701 Marburg Avenue, Cincinnati, Ohio  45209    
Xref: sparky comp.object:2954 comp.lang.c++:11273
From: feldman@toklas.enet.dec.com (Gary Feldman)
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 17:32:03 GMT
Reply-To: feldman@toklas.enet.dec.com (Gary Feldman)
Organization: Digital Equipment Corporation

In article <18822@drutx.ATT.COM>, weh@abasin.dr.att.com (William E. Hopkins)
writes:

|> 
|> Having just read two papers on Annotated C++ (a.k.a., A++; thanks Rich!),

Dare I ask what the two papers were, and where are they available?

   Gary
Newsgroups: comp.object
From: jch@rdg.dec.com (John Haxby)
Subject: Re: Is GC needed?
Keywords: robust
Organization: Digital Equipment Corporation
Date: Tue, 21 Jul 1992 14:55:34 GMT

In article <5677@osc.COM>, jgk@osc.COM (Joe Keane) writes:
|> In article <1992Jul13.133931.27924@bony1.bony.com> richieb@bony1.bony.com
|> (Richard Bielak) writes:
|> >Actually a problem much worse than memory leaks, is the problem of multiple
|> >deallocations. Multiple deallocation of the same chunk of memory is usually
|> >fatal...

[Comments about much improved allocators deleted]

GC is also needed to remove inter-module dependencies.
For examlpe, there was a bug in BSD4.2 with certain ethernet drivers
that showed up as a memory leak.  Basically, the IP code passed buffer
to the driver and forgot about it.  However, the driver did not free the
buffer since it couldn't tell whether or not the IP layer had done with it.

There are two equally inglamous ways of fixing this: one is to provide
reference counts in buffer headers, the second is for the IP layer to give
a copy of the buffer to the driver.  Both have been tried, both work.  The
second is slow and wasteful, the first requires a substantial re-write of the
kernel's memory management: essentially to introduce a reference counting
collector. I hope the cyclic references are dealt with....

Garbage collectors can be made arbitrarily fast given enough memory,
though that is a poor excuse.  However, reasonable garbage collectors in
sensible amounts of memory can give significant performance improvement.
Even stop-and-wait collectors can cut the down time to half a second and
still keep good performance.  Incremental collectors don't even have this
problem.

-- 
John Haxby, Definitively Wrong.
Digital				<jch@rdg.dec.com>
Reading, England		<...!ukc!wessex!jch>

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.
Xref: sparky comp.object:3015 comp.lang.eiffel:986
From: bruce@plsparc.UUCP (Bruce D Mount)
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: How to design a data structure library.
Summary: I agree with Richie
Date: 22 Jul 92 20:32:15 GMT
Followup-To: comp.object
Organization: Personal Library Software, Inc.

Yeah, what he said...Geesh, Richie stop reading my mind!

Seriously, I own SIGs Eiffel/S and have used ISE's Eiffel 2.3
quite a bit and pretty much agree with everything that Richie
said regarding library design (i.e. Multiple iterators ARE needed,
flat|short IS important, RISC IS better than CISC, etc...)

My main reason for using Net Bandwidth is to ask ISE (or anyone
else who knows) if the Basic libraries for ISE Eiffel 3 are the
same (roughly) as ISE Eiffel 2.3 or are they radically different?
(e.g. multiple iterators)

Would ISE care to comment (please, please)?

I would also like to congratulate Paul Johnson for summarizing 
what I think are the major issues in library design.

*  Bruce Mount    "Another member of the Eiffel Jihad!"
*  Internet        bruce@pls.com
*  Usenet       ...uunet!plsparc!bruce
*  Voice           (301) 990-1155
Newsgroups: comp.object
From: sally@projtech.com (Sally Shlaer)
Subject: Re: Help: OOA and OOD Methodologies
Organization: Project Technology, Inc., Berkeley, CA
Date: Tue, 21 Jul 1992 17:52:56 GMT

song @berault.ics.uci.edu (Xiping Song) writes:

> Shlaer/Mellor's weakness is on describing operation parts of an 
object.

If you haven't seen it yet, you might like to take a look at

     Object Lifecycles:  Modeling the World in States
     by Sally Shlaer and Stephen J. Mellor
     Prentice Hall
     ISBN 0-13-629940-7

This book came out last October.  It is all about formalizing the 
dynamic behavior of the objects
(states and processes/operations).

Sally Shlaer           sally@projtech.com
From: eriseman@dw3f.ess.harris.com (Eric Riseman)
Subject: System Integration and OO Job bidding in the commercial marketplace
Reply-To: eriseman@dw3f.ess.harris.com (Eric Riseman)
Organization: Harris GISD
Date: Thu, 30 Jul 1992 13:55:14 GMT

I didn't know where to place this question,  and since this question
(half of it) involves some OO,
this particular forum  seemed to be a good place to start.

How does an organization/group of people find out about the projects
available nationwide in the
commercial sector with regard to both OO and System Integration?  

As the focus of my division is governmental,  a group of people with
expertise in the aforementioned
fields would like to present to management the abundant opportunities in
the commercial sector.
Currently,  topics such as OO / System Integration are project
dependant.  The group in question
believes that these two topics can be exploded into  productive and
profitable segments of our
organization.    

The main objective behind this change of focus is three fold.  First, as
a company we must diversify
so that we can bring products to market faster and more efficiently. 
Second, there is a plethora
of commercial organizations out there that can benefit from our
expertise.  We have already
developed these critical skills, now lets put them to work for us
(instead of never using these
skills again because the project in question doesn't need/use it). 
Lastly, This IS THE TECHNOLOGY
OF THE FUTURE.  Lets be proactive instead of reactive.  

Thanks for all and any advice!
ESR

Mail Responses to :  eriseman@dw3f.ess.harris.com
From: jhuang@amgine.ssc.gov
Newsgroups: comp.object
Subject: re:Comments on Martin/Odell OOA & OOD methodology
Date: 31 Jul 92 14:58:28 GMT
Reply-To: jhuang@amgine.ssc.gov ()
Organization: Superconducting Super Collider Lab., Dallas, Texas


> Hi,
>	I am new to this net.  I`ve seen plenty of discussion of the
> Schlaer, Rumbaugh, Coad, and Booch methodologies, but does any one
> have any comments on Martin and Odell`s methodology as published this
> year in "Object-Oriented Analysis and Design".  I am particularly
> interested in how it compares to Booch, and Rumbaugh for developing
> medium to large scale projects.  Thanks in advance.
>
> -rod

me, too.

Jean 
---------------------------------------------------------------
System Development, Physics Research       (214) 708-6164
SSCL, MS2003                              jhuang@sscvx1.ssc.gov
2550 Beckleymeade Ave.
Dallas, Texas 75237
---------------------------------------------------------------
--
---------------------------------------------------------------
System Development, Physics Research       (214) 708-6164
SSCL, MS2003                              jhuang@sscvx1.ssc.gov
2550 Beckleymeade Ave.
Newsgroups: comp.object
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: Class methods (was: Re: How to design a data structure library)
Organization: multi-cellular
Date: Mon, 27 Jul 92 15:54:28 GMT

In article <5618@vexpert.dbai.tuwien.ac.at> mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner) writes:
>From article <1992Jul23.123609.11699@bony1.bony.com>, by richieb@bony1.bony.com (Richard Bielak):

[...]

>
>Yes, but you already have two sets, a, and b, either of which you can
>send the message to.  Nobody decrees that the receiver of a message
>has to be changed by it, therefore returning c is a valid way to do
>it.
>

Bertrand Meyer and others, suggest that methods of a class can be
broken up into "queries" and "commands". "queries" are functions,
which do not change the object and "commands" are procedures that do.

So in class SET we have:


     is_element (e : T) : BOOLEAN is  -- this is a query
         ....

     add_element (e : T) is           -- this is a command
         ....

     merge (b : SET) is               -- adds elements of 'b' into current
         ....                         -- this is a command

The question is then what is "union"? 

I want to use it to create new sets - as in a := x.union (c,d). It is
not clearly a command - it doesn't modify its object, but it doesn't
feel like a query either.

I'm proposing that it should be a "creation" method - not a query or
command, so that you can write:

     !!c.union (a,b)

which says "create a set which is a union of 'a' and 'b'". 

This statement clearly shows that a new object is created - this is
not immediatly clear if you write c := a.union (a,b) or even 
c := a.unionWith(b).


...richie



   


-- 
* 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 - *
Xref: sparky comp.object:3043 comp.lang.eiffel:1005
From: mst@vexpert.dbai.tuwien.ac.at (Markus Stumptner)
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: Class methods (was: Re: How to design a data structure library)
Date: 28 Jul 92 18:50:15 GMT
Organization: DB and ES Subdivision, TU Vienna

From article <92210.125846MKK2@psuvm.psu.edu>, by MKK2@psuvm.psu.edu:
> While your crystal clear traditional syntax is nice, I feel fine with
>    c = [a union:b];

The discussion is definitely NOT about syntax - there's nothing wrong
with what you wrote above.  It is about the level at which completely
ordinary binary operators are to be declared.
 
> As for using Class methods, I wouldn't mind if there was also a
>    c = [Set union:a :b];

I still think this is conceptual overkill for what amounts to the
equivalent of an addition operator.  Note that the Eiffel solution is
more radical still, since here the assignment to c is explicit.
-- 
Markus Stumptner                                mst@vexpert.dbai.tuwien.ac.at
University of Technology Vienna                 vexpert!mst@relay.eu.net
Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst
Newsgroups: comp.object
From: oscar@csis.dit.csiro.au (Oscar Bosman)
Subject: Multiple Inheritance: `mix-in' classes and derived types
Organization: CSIRO Division of Information Technology
Date: Tue, 21 Jul 1992 03:00:23 GMT


I have a design based upon some abstract classes (A, B, C, D, ... in the
diagram below) which I would like to mix and match to make my concrete
classes (L, M, N in the diagram).  So far this a standard 'mix-in'
design.

        A B  C  D E ...
        |\  /|   /|
        | \/ |  / |
        | /\ | /  |
        |/  \|/   |
        L    M    N ...

The problem occurs when I wish declare a function which operates on
all classes derived from both `A' and `C'.  Ideally I'd like to say
something like (in modified C++ syntax):

     foo(A & C my_obj) { ... }

where `&' indicates a kind of intersection of types.  I can see two
ways to do fudge this, neither of which I like.

1.  I could declare all the combinations of the `mix-in' classes (A_B,
A_C, B_C, ..., A_B_C, ...) and insist that concrete classes are
derived from the appropriate `combination' class.  But this is counter-
intuitive and makes it tedious to add new mix-ins.

2.  I could declare the argument to be of one type (say `A') and use
run-time type checking to check that the argument is also of the other
type before down-casting to a `combination' class.  In Sather this
might look like this (I don't think that the proposed type-safe down-
casting for C++ gives the correct behaviour because I don't want to
type-check against A_C).

class R is
   
   foo(a:$A) is 
      assert(pre) a.of_type(C::type) end;
      a_c: $A_C := a;

      -- do something with the `A' features of a_c
      -- do something with the `C' features of a_c
   end;

end; 

The problem here is that the compile should be able to type-check the
argument. 

There is a proposal to add `type adoption' to Sather 1.0 which would
go some way to solving my problems with solution 1 above.  As I
understand it, it would go something like this:

class A_C is 
   adopts L;  // A_C is now a superclass of L
   adopts M;  // A_C is also superclass of M

   foo(a:$A_C) is 
      -- do something with the `A' features of a
      -- do something with the `C' features of a
   end;

end; 


Does anyone have some experience with using mix-ins in this way. I'm
paticularly interested in solutions implemented in C++.

Oscar.
-- 
Oscar.Bosman@csis.dit.csiro.au          Centre for Spatial Information Systems
                                        CSIRO Div. Information Technology
phone: +61-6-2750912                    GPO Box 664
fax:   +61-6-2571052                    Canberra, 2601.    AUSTRALIA.
From: metz@iam.unibe.ch (Igor Metz)
Subject: Announcing: the OO Hall of Fame
Reply-To: metz@iam.unibe.ch
Organization: Dept. of CS, University of Berne, Switzerland
Date: Fri, 24 Jul 1992 12:33:13 GMT

Whenever I read an article or book I wonder how the author might look
like.  Long hair? Blue eyes? Contact lenses?
Most of the students in my C++ courses wonder how the inventor of C++
looks like. Probably because don't know how to pronounce the name
correctly :-)
That's why I decided to set up a "OO Hall of Fame" gallery. This
gallery is a directory on our anonymous ftp server which contains
scanned images stored as TIFF files. (I hope that there will be know
copyright problems...) Currently it contains pictures of

  Adele Goldberg
  Andrew Koenig
  Bjarne Stroustrup
  Brad Cox
  Grady Booch
  James Coplien
  Margaret Ellis
  Mark Linton
  Peter Coad
  Tony Hansen

This selection of pictures does not relect my personal taste! I just
didn't have more pictures. If you have a picture of Bertrand Meyer
or David Ungar or Rebecca Wirfs-Brock or any other well known OO
reseacher/author, let me know. I'll install it!

The files can be found on iam.unibe.ch [130.92.64.10]: ~ftp/Images/OO_Hall_of_Fame

---
Igor Metz <metz@iam.unibe.ch>
Institut fuer Informatik und angew. Mathematik, Universitaet Bern, Switzerland.
Phone: (0041) 31 65 49 90  Fax: (0041) 31 65 39 65

Newsgroups: comp.object,comp.lang.eiffel
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: Class methods (was: Re: How to design a data structure library)
Organization: multi-cellular
Date: Thu, 30 Jul 92 12:39:51 GMT

In article <1992Jul29.140357.26748@merlin.hgc.edu> jcm@hgc.edu (James McKim) writes:

[...]

>
>Yes, it's really the design of the _class_ that originally sparked
>this discussion, not the syntax used. It does seem that designing
>the standard set operations, string operations, etc as creation
>routines is an idea worth pursuing.
>

Thanks for adding a voice of sanity into this discussion, before it
degenerates into a flame war :-).

My observation was this, although Eiffel does not have "class methods",
as does SmallTalk, you can think of creation routines as class
methods.

During Object Expo I attended a talk by Meirl-Page Jones (sp?), in
which he suggested that certain methods *should* be class methods (he
was criticizing classes in Tim Budd's book "The Little SmallTalk").

The example he used was "arccos" (ie. inverse cos function). He
argued, that arccos, which returns "anAngle", should be a class method
in class "Angle", rather than an instance method in class "Real".

The reason was that he did not want to "encumber" the class "Real"
with class "Angle", as the two are not always used together. Another
words, making "arccos" a class method of "Angle" reduces class
coupling.

As another example, consider a routine, "string_to_real", which converts a
string to real number. According to the above argument, this routine
should be a creation routine in REAL. So you'd have code like this:

       !!pi.string_to_real ("3.14159");

The twist in Eiffel is that you cannot use a creation instruction in
an expression. But that's a different thread...


...richie



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