HDTenEightyP/NetNews huggingface dataset:
From: aras@multix.no (Arne Asplem)
Subject: SUMMARY: Book on Smalltalk-80's Model-View-Controller (MVC) architecture 
Organization: Multix A.S
Date: Mon, 28 Sep 1992 16:04:02 GMT

Several was interested in books on the Model-View-Controller. 
I received the following in response to my request. Thanx for all the
replies.


"A Cookbook for using the Model-View-Controller
User Interface Paradigm in Smalltalk-80",
by Glenn E. Krasner, Stephen T. Pope,
ParcPlace Systems, Palo Alto 1988.

"An Introduction to Object-Oriented Programming and Smalltalk"
by Lewis J. Pinson, Richard S. Wiener
Addison-Wesley Publishing Company, Inc.

"Inside Smalltalk, Volume 2",
by Lalonde and Pugh goes 

  -- Arne
-- 
//  Arne Asplem    //  Office:    Gjerdrums vei 12, N-0486 Oslo, Norway  //
//  Multix A/S     //  Phone/fax: +47-2-950800 / 950790                  //
//                 //  Email:     aras@multix.no                         //
//  NUUG Chairman  //  Email:     aras@nuug.no                           //
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Thu, 24 Sep 1992 12:59:34 GMT
Subject: Re: Re: Passing functions as parameters in an OO environment
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.object

In article ... ajs@prg.ox.ac.uk (Adolfo Socorro) writes:

   Higher-order functions are nice, but their functionality may be achieved
   with generic modules. 

If you're prepared to do all the explicit instantiations. If the instantiations
are implicit, why bother with generic modules -- they seem to be overkill for
the simple cases that HOFs are good for.

   Moreover, if you are worried about giving your language a
   formal semantics, you might want to stay away from higher-order logic.

Since a well-known theorem-proving system, namely Cambridge HOL, uses
higher-order logic as its basis, and for giving semnatics of sub-languages, I'd
like to know why you think this.

   Also, an appropriate module mechanism would allow you to impose semantic 
   constraints on the functions passed as parameters.

So would a more powerful type system.

   And in addition, with modules, dozens of functions may be substituted for
   dozens of other functions, giving increased leverage.

Unless I misunderstand you, the same thing applies with HOFs -- any suitable
call will be instantiated to the correct type. What's more, only the function's
you actually *use* are instantiated -- not their clamouring siblings.

[Stuff about FOOPS deleted]
--

Regards,    | ``The French teacher does not threaten. She says, | Teen
Kers.       | "s'il vous plait"''.                              | Agent
From: Daryl_Spitzer@mindlink.bc.ca (Daryl Spitzer)
Newsgroups: comp.object
Subject: Eiffel for Macintosh
Date: 2 Oct 92 14:56:39 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

All this talk of Eiffel has piqued my interest...are there any Eiffel
compilers
for Macintosh?

--
-------------------------------------------------------------------
 Daryl_Spitzer@mindlink.bc.ca     "Life isn't just, life just is."
         a2251@mindlink.bc.ca              -- Me  (I think.)
-------------------------------------------------------------------
From: patterso@gmuvax.gmu.edu
Newsgroups: comp.object
Subject: O-O SRS references
Date: 5 Oct 92 23:35:56 -0500
Organization: George Mason University, Fairfax, VA.

REFERENCES NEEDED!!

I am looking for references on the concept of an "object-oriented
software requirements specification" (OOSRS).  I am particularly
interested in the activities that must be accomplished b-e-f-o-r-e
the SRS is written -- to provide elements that are necessary
or desirable to support an object-oriented design.


I will post a follow-up article to summarize responses.  If you know of
such an article, please send information to  patterso@gmuvax.gmu.edu
                                             ^^^^^^^^
                                      (please note spelling)


Thank you!

Newsgroups: comp.object
From: shiva@vega.Stanford.EDU (Marcos Javier Polanco)
Subject: Agent-Oriented Programming: Request for Information
Organization: DSO, Stanford University
Date: Wed, 30 Sep 92 21:53:46 GMT



Hello.

I am looking for articles or papers on Agent-Oriented Programming.

If you could direct me to some I would certainly appreciate it.

Thanks.

-Marcos J. Polanco
-shiva@vega.stanford.edu
-415-691-2255
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Tue, 22 Sep 1992 15:03:23 GMT
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: Hewlett-Packard Laboratories, Bristol, UK.
From: bumesh@puma.cat.syr.edu
Subject: Metric for object communication
Organization: Syracuse University
Distribution: usa
Date: Tue, 29 Sep 92 15:23:04 EDT

I'm looking for any work on metrics for OOPLs. I've already seen some work
done by Shyam Chidambar and Chris Kemerer from Sloan school of mgmt!!
I'm specifically interested in trying to quantify object relationships
like inheritance, aggregation and acquaintance in "pure" OO languages.
I'll post a summary of all replies. Thanks in advance.
-umesh
--


-umesh
Xref: sparky comp.object:3801 comp.lang.smalltalk:1988 comp.lang.eiffel:1207
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 1 Oct 92 01:38:12 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <khaw.717868356@parcplace.com> khaw@parcplace.com (Mike Khaw) writes:
>In <1992Sep29.235000.3583@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
>
>>  Before this capability Smalltalk had some advantage over Eiffel in the speed
>>  of the turn around from change to testing. No one really likes
>>  waiting around for a compiler to test a change. In prototyping
>>  this can be a real drag. But now  Eiffel can compete with Smalltalk in this 
>>  area also. In fact it can be faster than Smalltalk in some applications
>>  because you only interpret the limited area you are changing. The rest of
>>  the classes are running at the speed of compiled code! That suits me 
>>  very nicely.
>>  nice.
>
>Ahem. One more time: compiled vs. interpreted is no more a language
>property of Smalltalk than it is of Eiffel. There are interpreted
>implementations of Smalltalk. ParcPlace Smalltalk is not interpreted.
>It uses a hybrid approach that ParcPlace terms "dynamic translation".
>For those unfamiliar with it, here's how it goes: When you define a
>method, the Smalltalk system converts it to bytecode (an intermediate
>representation). An interpreter implementation would interpret the
>bytecodes when this method is invoked. In ParcPlace Smalltalk, when
>this method is invoked, the running system first checks to see if the
>native machine code translation of the bytecodes is already present in
>an in-memory cache. If so, that native code executes directly from the
>cache with no interpretation overhead, "at the speed of compiled code"
>(to quote Des Kenny). If the native code representation is not in the
>cache, there is a slight overhead of translating the bytecode
>representation and then caching it. 

But the byte codes must be interpreted if they aren't in the cache.
This still adds overhead over complete compilation. But there are also
C++ implementations that use some level of interpretation. I tend to
avoid them.

Admittedly, the caching does make it faster than complete interpretation,
but it is still significantly slower than a compiled language. The more
complex the program, the greater the difference.



-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
Xref: sparky comp.object:3811 comp.lang.smalltalk:1999 comp.lang.eiffel:1214
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
From: Des.Kenny@bbs.actrix.gen.nz
Date: Fri, 2 Oct 1992 00:25:27 GMT
Organization: Actrix Information Exchange
Keywords: ISE, Eiffel, productivity, quality
Summary: ISE Eiffel productivity and quality balance						

In article <1992Oct1.152830.18503@informix.com> cshaver@informix.com (Craig Shaver) writes:
> In article <1992Oct1.013812.2130@jetsun.weitek.COM> nadja@jetsun.weitek.COM (Nadja Adolf) writes:
> >In article <khaw.717868356@parcplace.com> khaw@parcplace.com (Mike Khaw) writes:
> >>> .... other stuff ....
> >>
> >>Ahem. One more time: compiled vs. interpreted is no more a language
> >>..... other stuff ....
> >
> >But the byte codes must be interpreted if they aren't in the cache.
> >This still adds overhead over complete compilation. But there are also
> >...... other stuff ...
> >Admittedly, the caching does make it faster than complete interpretation,
> >but it is still significantly slower than a compiled language. The more
> >complex the program, the greater the difference.
> >
> Two of the biggest knocks on smalltalk are speed and size.  These are
> real concerns in real business situations and get right to the heart of
> cost per seat.  In large organizations this will make a difference.
> 
> IMHO the cache scheme of Parc may be overblown as a real world speed up.
> It will depend on the application.
> 
> In looking at smalltalk code I can readily see many areas that need rework
> in the basic classes.  Many of the methods in smalltalk are
> implemented in an inefficient manner that impacts iterative use.
> 
  I guess we are talking about specific implementations of a language
  in this context.

  In addition to the time it takes to edit a module of an application
  and test the result. There are also other important software engineering
  issues for large systems in industry to consider.

  In ISE Eiffel 3 we still have static type checking even with an 
  interpreter/compiler mix. This may be more important for the quality
  of a system in the longer term. Rapid development of modules with
  no static type checking may risk type failure in production. So what
  is really rapid about having to fix type errors at the production stage?
  I am sure there are some Smalltalk developers who rarely allow type
  errors into production. But is it not better to let these errors be
  eliminated by the development tool before production? I prefer the
  environment to help me as much as possible with quality assurance
  as early as possible in the lifecycle.
From: j_ohearn@dsg4.dse.beckman.com
Newsgroups: comp.object
Subject: Re: OOP not GUT of programming?
Date: 6 Oct 92 15:10:53 GMT

In <5OCT199215551226@elroy.uh.edu> st1lv@elroy.uh.edu (McLeod, Stephen) writes:

   >Hello,  back again with another question.

   >OOP is gaining popularity right now and pretty soon I'm sure they will be trying
   >to use it to do everything but is OOD/P really *that* good?

   >I have been talking to a lot of people about this lately and some had the view
   >that OOP was basically a good algorithm for handling the data base handling
   >aspect of a solution be it an OS, a Database, or a guided missile program but
   >that it was not appropriate for writing, say, a compiler, a text editor and
   >so on.

   >What do you think?  I'd appreciate your views on this as I am floundering around
   >looking for a topic to write a paper on and 'the limits of the ood paradigm' 
   >seems pretty good right now.

This posting inspired me to share some thoughts I have had concerning the worth of
OO techniques.

The benefits of OO have nothing to do with any particular application (e.g. a compiler
a text editor, a database, an OS...).  However, it has everything to do with providing
the means to COMMUNICATE more clearly and succinctly (the focus is on what the system
is, not just what it should do).  OO techniques allow us to create more reasonable
abstractions by focusing on the entities enherent to the system being constructed.

Structure techniques commit a grave error by regarding processing and data as seperate
enterprises.  Such a decision confuses engineers because it ignores the powerful relation-
ships between processing and data.  Furthermore, the entities which define a system
become useless as points of reference because the processing and data which are inherent
to an entity are scattered throughout the design.

OO represents a philosophy which will provide tremendous advantages if used properly.
The entities inherent to a problem domain should represent the primary focus when
designing and implementing a software system.  The second most important issue is
the relationships between those entities; these relationships serve to uncover hidden
system issues.

Thank you for listening (unfortunately, I have more thoughts on the matter but I have
precious little time at the moment).

Jim O'Hearn
Software Engineer
Beckman Instruments, Inc.
Diagnostics Systems Group
Newsgroups: comp.object
From: etxjnor@solsta.ericsson.se (Jan Norden  TX/DK)
Subject: Rambaugh drawing tool
Organization: Ericsson
Date: Tue, 29 Sep 1992 11:46:02 GMT

I don't need anything fancy, just a quick way to draw and edit the diagrams.
(If there is more, that would be nice of course, but not really
needed at this point).

The operating environment should be SUN4 or PC.

Please reply via a-mail. I will summarize if there is interest.


--
--
Jan Norden, Ericsson Telecom AB | E-mail: etxjnor@solsta.ericsson.se
KS/ETX/TX/DK                    | Voice.: +46 54 193168 Fax...: +46 54 152509
S-652 21 KARLSTAD , SWEDEN      | Memo..: ERI.ETX.ETXJNOR
From: dsr@bnr.co.uk
Newsgroups: comp.object
Subject: Methodology Competition
Date: 5 Oct 92 14:46:10 GMT
Reply-To: dsr@bnr.co.uk ()
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

There's many people on the net who all enjoy their own methodology
and prefer it to all others.  Would any of these people care to try
out their chosen OO methodology on a Case Study of a system?

It would be nice to have volunteers to analyse and design the
system using one of the advertised OO methods, e.g. Wirfs-Brock,
Rumbaugh, ShlaerMellor, Booch etc.. such that we get an analysis and
design for each method.

The case study is currently being used as part of a Ph.D. thesis by
Audrey Mayes of Loughborough University, England to compare and
contrast various methods.

If you're interested, and have time, to apply a methodology to the
case study then please drop me a line and we'll get things rolling.

This is the case study...


> Copyright: Audrey Mayes, Loughborough University
>
> Case Study:  System for planning crops in a garden
> 
> The system is required to store all the information required to allow
> a gardener to plan the growth of crops.  There is a requirement to
> plan the maturation of crops, for example to avoid crops maturing when
> the gardener is on holiday or when there is a strong likelihood of
> attack by pests.  The variation in planting time and growth period
> of a crop depending on the region of the country needs to be catered
> for.  The gardener also wishes to be able to divide the garden into 
> plots to allow for crop rotation to be carried out.  Reports should
> be produced to give relevant information about the productivity of
> the vegetable garden.  The gardener also requires to be able to add
> or change the information concerning crops.


Dave


   Dave Riches
   Email:  David.S.Riches@bnr.co.uk
   Smail:  BNR Europe Ltd, London Road,
           Harlow, Essex. CM17 9NA.  England
   Phone:  +44 (0)279-402496
   Fax:    +44 (0)279-451434
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: comparing object-oriented platforms
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Sun, 4 Oct 1992 12:29:11 GMT

In article <1992Oct1.013812.2130@jetsun.weitek.COM> nadja@jetsun.weitek.COM (Nadja Adolf) writes:
>
>Admittedly, the caching does make it faster than complete interpretation,
>but it is still significantly slower than a compiled language. The more
>complex the program, the greater the difference.

	This need not be the case. The small code sizes may reduce 
the overheads of loading machine code from virtual memory if the byte
codes are interpreted.

	Secondly, delayed binding can be delayed even further in
interpreted systems than compiled ones (even if this isnt the case
in Smalltalk, it certainly is in other interpreted languages
like Postscript and TeX) and the mechanism to implement the
same functionality in the compiled system may be just an
expanded version of the same thing---which might even run slower
as well, being compiled by an 'optimising' compiler instead
of executed by a hand crafted interpreter.

	The IBM PL/1 compiler used to use a hybrid compiled/interpreted
scheme I believe. I think some of the IO operations, and some
of the picture formating was interpreted.


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
From: gramsey@atlas.nafb.trw.com
Newsgroups: comp.object
Subject: home-based computer biz?
Date: 27 Sep 92 19:15:58 PST

hi net people

i'm posting this for a friend without net access please e-mail to my 
account and i will forward to him 

					thanx   greg


i'm interested in starting a home-based computer business, just heard about
Gerhard Reeg company.  They are offering a license that allows me to hook into 
their network of buyers and sellers and i have to culivate my own client base.
Has anyone heard of this company?  Any information and/or additional avenues 
of investigation would be appreciated.

					Thanks Kevin
From: richieb@bony1.bony.com (Richard Bielak)
Subject: OO Concurrency (was Re: comparing object-oriented platforms)
Keywords: wait-by-necessity
Organization: multi-cellular
Date: Wed, 30 Sep 92 12:33:09 GMT

In article <1992Sep29.105314.14564@dsg.cs.tcd.ie> cjmchale@dsg.cs.tcd.ie (Ciaran McHale) writes:

[...]

>
>Don't you mean to say "As far as lots of OO languages are concerned..."
>Eiffel is not unique in being used as a host language to test ideas on
>synchronisation.
>
>Of the proposals I have seen for synchronisation mechanisms, for
>whatever language, none are perfect. We (people doing research in this
>area) have been making great progress over the last few years but don't
>expect any OO language, Eiffel included, to have a wonderful
>synchronisation mechanism "real soon now."

One very neat idea for synchronization was proposed by D. Caromel. He
called it "wait-by-necessity" (also called "lazy wait"). The idea is
that an thread will have to wait for a result of concurrent
computation, only at the point where it is needed. In Eiffel syntax:

   x := obj1.compute_something;  -- this starts asynch computation

   ... -- continue execution here, without references to 'x'

   x.last_computed; -- now that we need the result, we may have to
                    -- wait for it


[...]
>
>One major problem I see with any synchronisation mechansism for Eiffel
>which tries to support internal concurrency is the conflict between
>internal concurrency and the evaluation of pre/postconditions. (What are
>the semantics for evaluating pre/postcondition when instance variables,
>which they access, are being updated by a thread executing an operation
>of the object?) From my reading, it seems that CEiffel doesn't address
>this issue. (I haven't read the paper by Karaorman & Bruno so I don't
>know if they have a solution for this.)
>

Regarding the pre- and post-conditions, I thought of the following way
of dealing with this problem. 

You can divide features of a class into "querries" and "commands".
Querries only read the object's attributes and return some value.
Commands modify the object.

So, multiple querries can run at the same time and the pre- and post-
conditions will be fine. However, commands can only be executed one at
a time.

This is very similar to the idea of locks in a database. When an
object in a database is "read" locked many people can read it at the
same time. But to modify the object, you have to get an exclusive
"write" lock.


...richie


-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
From: gor@cs.strath.ac.uk (Gordon Russell)
Newsgroups: comp.object
Subject: COMANDOS Project Details Wanted
Date: 6 Oct 92 08:44:48 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.


 Hi there,
   Is there anyone out there who have some references to COMANDOS? It
appears to be a hard object-oriented system to track down, but ever
since my supervisor saw a demo of it he has been on to me to include it in
my thesis. If you have some information on this system, could you email it
to me? If there is demand, I will post a summary to the group.
   Thanx in advance,
        Gordon

+--------------------------------+-------------------------------------------+
|  Gordon Russell                |  EMAIL     : gor@cs.strath.ac.uk          |
|  L13.13a, Livingstone Tower,   |  TELEPHONE : 041-552-4400   Ex 3703       |
|  University Of Strathclyde,    |  FAX       : 041-552-0775                 |
|  26 Richmond Street,           +-------------------------------------------+
|  Glasgow, G1 1XH               | Spelling mistakes within this document are|
|  Scotland, UK                  | caused by internet compaction algorithms. |
+--------------------------------+-------------------------------------------+
From: dsr@bnr.co.uk
Newsgroups: comp.object
Subject: Competition
Date: 5 Oct 92 14:43:11 GMT
Reply-To: dsr@bnr.co.uk ()
Organization: BNR Europe Limited, London Road, Harlow, Essex, GB

There's many people on the net who all enjoy their own methodology
and prefer it to all others.  Would any of these people care to try
out their chosen OO methodology on a Case Study of a system?

It would be nice to have volunteers to analyse and design the
system using one of the advertised OO methods, e.g. Wirfs-Brock,
Rumbaugh, ShlaerMellor, Booch etc.. such that we get an analysis and
design for each method.

The case study is currently being used as part of a Ph.D. thesis by
Audrey Mayes of Loughborough University, England to compare and
contrast various methods.

If you're interested, and have time, to apply a methodology to the
case study then please drop me a line and we'll get things rolling.

This is the case study...


> Copyright: Audrey Mayes, Loughborough University
>
> Case Study:  System for planning crops in a garden
> 
> The system is required to store all the information required to allow
> a gardener to plan the growth of crops.  There is a requirement to
> plan the maturation of crops, for example to avoid crops maturing when
> the gardener is on holiday or when there is a strong likelihood of
> attack by pests.  The variation in planting time and growth period
> of a crop depending on the region of the country needs to be catered
> for.  The gardener also wishes to be able to divide the garden into 
> plots to allow for crop rotation to be carried out.  Reports should
> be produced to give relevant information about the productivity of
> the vegetable garden.  The gardener also requires to be able to add
> or change the information concerning crops.


Dave


   Dave Riches
   Email:  David.S.Riches@bnr.co.uk
   Smail:  BNR Europe Ltd, London Road,
           Harlow, Essex. CM17 9NA.  England
   Phone:  +44 (0)279-402496
   Fax:    +44 (0)279-451434