HDTenEightyP/NetNews huggingface dataset:
From: pkr@media03.UUCP (Peter Kriens)
Newsgroups: comp.object
Subject: Can functions be objects?
Date: 22 Jul 92 08:29:06 GMT
Organization: Mediasystemen, Netherlands
X-Newsreader: Tin 1.1 PL4


Functions as objects
I started using OO with Smalltalk about 6 years ago. After
making a million of mistakes I finally have the feeling
that today I create reasonable efficient OO models and
designs. 

Lately I am involved in projects where C++ is used. This
projects confront me with designs which I find very 
awkward. I know C++ requires a different design attitude.
Classes are much cheaper and because of the static typing
you need much more of them. I realize this creates a more 
complex design.

However, I get the uneasy feeling that I am missing
something because everybody else seems to find function objects
which I regard as bad. Even in the book of Rebecca Wirfs-Brock 
I am confronted with an Inquiry, a Deposit and a Withdrawal object
in the ATM. In a design I am reviewing I find a XX_Create, XX_Delete 
and a XX_Edit object.

My personal feeling is to immediately reject these kind of objects
because they feel like they were found from structured analysis
instead of object oriented analysis. They could be there because
people need an abstraction mechanism to collect together a group
of functions, and that is what they call a class. 

I feel strongly that an object should play an active rol in the
problem domain. The Inquiry or Withdrawal are not tangible things,
but just services executed by "something". By definition, the Inquiry, 
the Withdrawal etc. will be closely tied together, because they will
use the same kind of input/output devices and basic services.

Seperating these into a seperate class makes the communication pattern
needlessly complex. And the fact the the person who wants to understand
the program needs to understand more classes, will increase maintenance
cost.

Why I post this question is to find out if these kind of
objects are commonly regarded as good OO, and that I am
standing alone, or that I am right. 

Are there things I am missing? Can "functions" 
be objects?

	Peter Kriens



Newsgroups: comp.object
From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: Re: Thoughts on the Progression from SA/SD Models to OO Models
Organization: Northern Telecom Inc, Mountain View, CA
Date: Thu, 30 Jul 1992 18:57:37 GMT

In article <1992Jul30.025233.19890@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:
|> > I think a significant aspect of the Information Model as 
|> > described in Shlaer-Mellor is the fact that it (seems) heavily influenced
|> > by the dictates and constraints of relational database modelling techniques.
|> > In my opinion, the relational view of data is not as general or natural as
|> > the object oriented view. While in some cases a relational model of data
|> > will be most appropriate, in other cases it surely will not be. I'm a bit
|> > concerned that the Shlaer-Mellor might force, or at least coerce,
|> > implementations to adopt the relational modelling of data. 
|>  
|> > Any comments?
|> 
|> I think that the E/R models of information and data transcend SA/SD,
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> Codd's Normal Forms, OO, and other approaches.  My view, held for only
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I agree. You seem to equate E/R modelling with relational database modelling. 
It is true that the first step in building a relational model is building
an E/R model. However, the normalization of data for the relational model
is not necessarily part of E/R, and it is this normalization which Shlaer-Mellor
prescribes that I'm concerned with.


|> about a year but not seriously challenged by anything, is that they
|> these models are as fundamental to software engineering as circuit
|> theory is to electrical engineering, or stochiometry to chemical
|> engineering.  (Which is not to denigrate SA/SD, nth Codd Normal Form,
|> OO, or any of the other approaches ...)
|> -- 
|>  (This man's opinions are his own.)
|>  From mole-end				Mark Terribile
|> 
|>  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.object
Subject: Re: Is GC needed?
Date: 25 Jul 92 13:16:39 GMT
	<1992Jul10.165626.7864@visix.com> <4567@balrog.ctron.com>
	<AXEL.92Jul24154632@avalanche.cs.tu-berlin.de>
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: axel@cs.tu-berlin.de's message of 24 Jul 92 14:46:32 GMT

>>>>> On 24 Jul 92 14:46:32 GMT, axel@cs.tu-berlin.de (Axel Mahler) said:
Axel> Nntp-Posting-Host: avalanche.cs.tu-berlin.de

Axel> Have there been any attempts to employ multi-processor shared-memory
Axel> computer architectures for solving the GC problem ? Why not have a 
Axel> dedicated GC processor that frees the application from worrying about
Axel> memory management ? I've not given the idea a great deal of thought, so
Axel> it might actually be stupid or unfeasible. Comments ?

I regret I have no references handy, but yes indeed it is an idea that has
been worked on some. First, collection concurrent with computation is a
venerable problem, studied by Dijkstra, among others, with a number of
proposals, some of them really implemented. Second, firmware or other
distinctive hardware support for concurrent or overlapped gc (or parts of gc)
has also been explored a bit. Doing hardware always has the problem of getting
people to accept it, and the steep curve to get it implemented, integrated,
etc. Third, gc within a concurrent shared memory system, either by separate
dedicated processes/threads (could be dedicated cpus) or by threads that
alternate between computation and collection are things that have been and are
being investigated. So, no, it's not a stupid idea. The hard part is getting
the overhead of coordination low enough to make it pay, unless you're doing
systems where predictability is more important than absolute resource
consumption.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
From: gt4084c@prism.gatech.EDU (SRINIVASAN,K)
Newsgroups: comp.object
Subject: Re: Can functions be objects?
Date: 23 Jul 92 20:18:50 GMT
Organization: Georgia Institute of Technology

In article <2840@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:
>
>Functions as objects

>Even in the book of Rebecca Wirfs-Brock 
>I am confronted with an Inquiry, a Deposit and a Withdrawal object
>in the ATM. 

Look at the functions as Events about which you wish to store some
attributes.  In your example of Withdrawal, time taken, money withdrawn,
etc., belong better to a withdrawal object than to the object representing
the person who withdrew the money, right?

BTW, I do modeling of manufacturing enterprises.  The structured models
usually have a function model and an information model.  When I started
with OO modeling, I thought only the contents of the info. model will
be classes and the functions will be methods of these classes.  However,
I realized the need for 'function classes' real soon.

-- 
SRINIVASAN,K
School of Textile Engineering   Georgia Tech.
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gt4084c
ARPA: gt4084c@prism.gatech.edu
Newsgroups: comp.object,comp.specification
From: haim@dancer.uucp (24103-kilov)
Subject: Re: Current OOA/OOD and formal methods
Reply-To: haim@dancer.UUCP ()
Organization: Bellcore, Livingston, NJ
Date: Fri, 31 Jul 92 16:56:51 GMT
Keywords: A++, Z, VDM, formal methods, OOA/OOD

There is a common ground. In fact, consider a graphical notation just like any
other notation and define it formally. If a graphical notation denotes in
an unambiguous manner components of precisely defined libraries then you
have sort of a synthesis of the two. We have attempted to do that for generic
object classes encountered in information modeling. These classes represent 
associations, and each of them is defined by means of the invariant and the
pre- and postconditions for the CRUD operations. After that is understood, 
you can provide a graphical notation for these associations (which is close
to an extended ER). Note that these classes are defined on the basis of
behavior.

As I have mentioned in comp.object before, we have published something in 
TOOLS '91 and also, more recently, as a Bellcore document "The Framework:
a Disciplined Approach to Analysis".

Hope this helps.

-Haim Kilov

haim@bcr.cc.bellcore.com      or
haim@dancer.cc.bellcore.com
From: smith@ctron.com (Larry Smith)
Newsgroups: comp.object
Subject: Re: Is GC needed?
Date: 22 Jul 92 19:06:28 GMT
Reply-To: smith@ctron.com
Organization: Cabletron Systems, Inc.

In article <1992Jul10.165626.7864@visix.com>, adam@visix.com writes:

>Have a little imagination, leave room for other paradigms.  I am less
>fortunate than most people in that I don't know the perfect solution,
>but I do think about it and if I come up with anything y'all'll be
>the first to know :-).

Okay, I'll bite.  What *is* one alternative to GC besides malloc/free???

Larry Smith (smith@ctron.com) No, I don't speak for Cabletron.
-------------------------------------------------------------
Daily I'd go over to Congress - that grand old benevolent national asylum - and
report on the inmates there.  Never seen a body of men with tongues more handy,
or information more uncertain.  If one of those men had been present when the
Deity was on the point of saying "Let there be light" we never would've had it.
From: davids@eng.auburn.edu (David Schreibman)
Newsgroups: comp.object
Subject: actor-based languages
Date: 24 Jul 92 15:20:50 GMT
Article-I.D.: news.1992Jul24.152050.6443
Reply-To: davids@eng.auburn.edu
Organization: Auburn University Engineering


	Can anyone provide a list of languages that are actor-based?

	Thanks in advance to anyone who can answer.

	-David (davids@eng.auburn.edu)
Xref: sparky comp.object:2989 comp.lang.eiffel:982
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: 24 Jul 92 10:58:49 GMT
Organization: DB and ES Subdivision, TU Vienna

From article <1992Jul23.123609.11699@bony1.bony.com>, by richieb@bony1.bony.com (Richard Bielak):
> The interesting question is which class should the routine "union" be
> in?  If a, b, and c are of type SET and "union" is a feature of SET,
> then we have:
 
>       c := a.union(a,b);

No.  "Binary operator" means that the receiver is one of the
arguments.  With explicit binary operators (as in C++ or Smalltalk),
you would write (if "+" expresses union)

c := a + b

That way, "+" is a message declared for sets, and used on sets.  If
you want a named message, you would write

c := a.union(b)

(Still looks odd, but lacks that redundant third parameter)

> In Smalltalk lingo, "union" should be a "class method".  The essence of
> a class method is that it can be invoked when the object of the given
> class does not exist yet.

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.

-- 
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: haim@dancer.uucp (24103-kilov)
Subject: Re: OO Literature
Reply-To: haim@dancer.UUCP ()
Organization: Bellcore, Livingston, NJ
Date: Wed, 22 Jul 92 05:44:55 GMT


I have published "Object concepts and bibliography" prepared for the ANSI
Object-oriented database task group, in SIGPLAN Notices in (I think)
October 1991. It contains several dozen references that are worthy and,
hopefully, none that are not...

Hope this helps.

-Haim Kilov
haim@bcr.cc.bellcore.com    or
haim@dancer.cc.bellcore.com
Newsgroups: comp.object,comp.lang.eiffel
From: steinman@is.morgan.com (Jan Steinman)
Subject: Re: Class methods (was: Re: How to design a data structure library)
Organization: Morgan Stanley & Company
	<5631@vexpert.dbai.tuwien.ac.at>
	<1992Jul28.150114.25065@bony1.bony.com>
Date: Tue, 28 Jul 1992 23:45:19 GMT

In article <1992Jul28.150114.25065@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:

   Perhaps "+" _should_ be a class message. Again, "+" is not a
   "query" or a "command". For numbers, "absolute_value" or "sign" are
   examples of queries, and "increment" is a command.

   What is "+"? You could say it's a query, as it doesn't change the
   object, which asks "what is the sum of self and the argument".

   But in math, a "+" is an operation on _integers_ (i.e. a class
   method) which given two integers, produces another one.

I think the hang-up on queries or commands is getting in the way here,
as is the class-object distinction. Objects are created continuously
and rapidly; many messages need to return newly created objects, and
if you insist that only classes can return new objecs, you'll get in
trouble quick!

If you must think in terms of categories of messages, how about adding
a third: "collaboration". aMan and aWoman collaborate to create aChild
-- they don't ask either Manness or Womanness to do it for them!
Likewise, "3" and "4" can collaborate to create "7", "1", or anything
else that is legal among consenting adults.

Likewise with Sets. It obviously takes both of them to produce a
union; a Set class is merely an uninterested third party in their
happy union!

In Smalltalk, collaboration is used frequently in double-dispatching.
I think Ingals had a nice paper on it.
--
: : Jan Steinman	   steinman@is.morgan.com		 Bytesmiths : :
: : 2002 Parkside Court				   West Linn, OR 97068-2767 : :
: : 503/657-7703					       212/956-8722 : :
From: sbate@atl.ge.com (Stephen Bate)
Newsgroups: comp.object
Subject: Re: Wanted info. on OMG, ORB, CORBA
Date: 30 Jul 92 20:53:53 GMT
Reply-To: sbate@atl.ge.com
Organization: GE Advanced Technology Laboratories

HyperDesk says they have developed their product in "strict compliance"
with the OMB ORB standard. Their address is:

HyperDesk Corporation
2000 West Park Drive
Westborough, MA 01581
Tel: (508) 366-5050
Fax: (508) 898-3841
--
Stephen Bate                |
GE Advanced Technology Labs | Internet: sbate@atl.ge.com
300 Route 38, Bldg. 145-2   | Voice: 609-866-6603
Moorestown, NJ 08057        | Fax:   609-866-6397
Newsgroups: comp.object
From: pramoon@doi.cs.keio.ac.JP (Pramoon Sermsuk)
Subject: OO Development
Reply-To: pramoon@doi.cs.keio.ac.jp
Organization: Doi Lab., Dept. of Computer Science, Keio Univ., Japan.
Distribution: comp.software-eng
Date: Fri, 24 Jul 1992 07:52:57 GMT


For my PhD research, which concerns Object Oriented Computing,
I'm looking for 
  - tools for OOA/OOD supporting methods from the most known authors like
    Booch, Rombaught,...
  - Some C++ code generators from the definition in the OOA/OOD tool.
Can you give me some more information? 
Can I find some free, publicly available, version?

Please e-mail directly.
Thanks in advance.

Pramoon
pramoon@doi.cs.keio.ac.jp
Newsgroups: comp.object
From: joe@solomon.technet.sg (Joseph Doo)
Subject: Info on OOA Methodologies
Organization: National University of Singapore
Date: Tue, 21 Jul 1992 11:37:27 GMT

I'm looking at OO Analysis Methologies and there are four major methodologies
I'm facing with:

1. Booch
2. Rumbaugh
3. Shlaer & Mellor
4. Rebecca Wirfs-Brock

Can anyone tell me what're the pros and cons of the methodologies? Does anyone
know of technical reports and case studies done in the evaluation of these
methodologies?

Thanks in advance.

Newsgroups: comp.object,comp.lang.eiffel
From: geoff@flash.bellcore.com (Geoffrey Clemm)
Subject: Re: Class methods (was: Re: How to design a data structure library)
Organization: Bellcore
	<GEOFF.92Jul27100601@wodehouse.flash.bellcore.com>
	<graham.712278529@galois>
Date: 28 Jul 92 10:00:15

In article <graham.712278529@galois> graham@maths.su.oz.au (Graham Matthews) writes:
   (Geoffrey Clemm) writes:
   >I believe you missed the central point of Richie's article, namely that
   >Eiffel 3.0 has a clean way of handling this situation, to quote:
   >In article <1992Jul23.123609.11699@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
   >> Given this, the above call to "union" would be written like this
   >> (using Eiffel 3 syntax):
   >>     !!c.union (a,b);
   >> Which I think is better. 
   >With which I completely agree.  This avoids the unpleasant assymetry
   >of c:=a.union(b).

   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.

Yes, generic functions are great, and languages like CLOS let you do
just this.  Unfortunately, the uncontrolled nature of inheritance for
generic functions can rapidly lead to a maintenance (and control flow)
nightmare, something which is of great concern to Eiffel users.

The alternative, namely, an artificial assymetry around the first argument,
is somewhat mitigated in Eiffel through the availability of creation
instructions, (and would have been even more mitigated with the
availability of creation expressions, as I have argued elsewhere :-).

Cheers,

Geoff
--
geoff@bellcore.com
Organization: Penn State University
Date: Wed, 22 Jul 1992 11:53:08 EDT
From: <MKK2@psuvm.psu.edu>
Newsgroups: comp.object
Subject: Re: A question of notation

>In a "standard" OO language to invoke method M in object
>O one writes something like,

>        a = O.M( .. )

>Now for historical reasons this kind of notation would not
>fit well with our existing language. The following alternative
>has been proposed

>        a = M( O, ... )

Your "standard" is C++ like (and some other languages).  In fact, the
compiler or pre-processor converts it into something like your second
alternative.

         a = sendmessage(M, O, ...)

to be a little more precise.  It shouldn't make any difference, it seems
to me.

There are other possibilities, too.  Smalltalk and ObjC use similar
notations, something like

      a = [O M:...];

You could make up anything that implies messages being sent.  How 'bout

     a = M(...) => O



have fun
From: budd@fog.CS.ORST.EDU (Tim Budd)
Newsgroups: comp.object
Subject: O.M() vs M(0) notation
Date: 24 Jul 92 17:36:55 GMT
Article-I.D.: CS.1992Jul24.173655.5869
Organization: Oregon State University, Computer Science Dept.

I agree that the O.M(...) notation clearly marks the receiver as special,
and seems more natural to most folks.

In our multiparadigm language LEDA (which has nothing to do with the C++
classes of the same name distributed by somebody in Germany), we wanted
to combine features of object oriented programming and functional
programming.  Part of this is the desire to permit methods to be
used as functions - that is, passed as arguments to higher level functions,
and so on.  Our solution was to permit easy (implicit) convertion between
the ``method'' type and the ``function'' type - when a qualified method
name is used in a context where a function is required (say, as an
argument), it is magically converted into a function, including adding
an argument to the front of the argument list.  Thereafter it is
invoked using the functional M(O) notation.

For the sake of symmetry we also allowed the reverse.  If you defined
a function that used an object as the first argument, you could invoke
it using the O.M() notation -- if the complier could not find a method
of a given name it would then look for an appropriate function.  This has
not provem to be quite as useful, and I am not sure it will remain in the
language.

--tim budd, oregon state university
From: mat@mole-end
Subject: Re: Help: OOA and OOD Methodologies
Keywords: OOA, OOD, Software Design, Software Analysis
Organization: :
Distribution: usa
Date: Wed, 22 Jul 1992 18:19:12 GMT

In article <2A66F3CE.13821@ics.uci.edu>, song@berault.ics.uci.edu (Xiping Song) writes:

>  One possible strength (or weakness to some people) is that Shlaer/Mellor
> method describes the object-oriented concept from the view of the relatioanl
> data model. This is very comprehensible for the people who have the relational
> modeling experiences.

Relational data model, or Entity-Relationship model?  E/R is very useful
to the Relational model, but they are seperable concepts.

>  Shlaer/Mellor's classification on the attributes is unique and more
> explicit than other OODs. (referece, naming, descriptive, ...)

>  Shlaer/Mellor's classification on the relationships between classes(objects)
> is unique. It is based on the mapping relationships (1-1, 1-m, n-m,
> conditional 1-1, ...). This might be most useful for certain application
> domains.

Yes, the Sh/Me viewpoint emphasises the data model.  I think that a strong
data model is a good component of OOA.
 
>  Its weakness is on descrbing operation parts of an object.

I think it has other weakneses as well.  In particular, it seems better
suited to identifying and describing the types that describe the Application
and Subject-specific parts of a program, and weaker in dealing with types
whose purpose is to express Programming technologies (types that support
or embody algorithms, that provide lists and iterators and the like, etc.)
In fairness, most OOA/D methods have the same weaknesses.

It also doesn't provide a good model above the object level; IMO the
`architecture' Shlaer and Mellor provide echoes the procrustian bed
approach of SA/SD.  Something better is needed, something that expresses
features of the problem.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 uunet!mole-end!mat, Somewhere in Matawan, NJ
Newsgroups: comp.object
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Class methods (was: Re: How to design a data structure library)
Organization: multi-cellular
Date: Thu, 23 Jul 92 12:36:09 GMT

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

[...]

>It seems to me that Union (I think ISE used 'merge' as the verb 
>form of union), Intersection and Difference (ditto for 'subtract' here)
>are fundamentally binary operations. That is, they're single valued
>functions of two variables, and so should be designed as such.
>Thus I favor the c := a + b or c := union( a, b ) form. I would
>add union, intersection, and difference as a first increment,
>through inheritance, to the minimal SET class.
>

The interesting question is which class should the routine "union" be
in?  If a, b, and c are of type SET and "union" is a feature of SET,
then we have:

      c := a.union(a,b);

Which looks a little odd :-).

In Smalltalk lingo, "union" should be a "class method". The essence of
a class method is that it can be invoked when the object of the given
class does not exist yet. In Eiffel terms, a class method is a 
creation routine.

Given this, the above call to "union" would be written like this
(using Eiffel 3 syntax):

    !!c.union (a,b);

Which I think is better. 



...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:3037 comp.lang.eiffel:1003