HDTenEightyP/NetNews huggingface dataset:
From: mcgredo@bluto.ie.orst.edu (Don McGregor)
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Reply-To: mcgredo@bluto.ie.orst.edu
Organization: Oregon State University - Univ. Computing Services
Date: Thu, 16 Apr 1992 04:26:16 GMT

Mark Lanett writes
>
>A friend bought a NeXT(he's an experiences MacApp/C++ developer)and has not
>been terribly impressed with NextStep.One of his biggest complaints is that
>he *isn't* getting "method not defined for this object". Next has their
>doesNotUnderstand message just swallow everything and not provide any error
>messages at all!

He must be doing something strange.  Quoting from the NeXT docs,  
-doesNotRecognize:

"Handles aSelector messages that the receiver doesn't recognize....It, in  
turn, invokes the error: method to genrate an error message and abort the  
current process."

The error: message prints out a short message on the console (or the tty if  
the program was started from the command line) to the effect that "Class foo  
does not recognize method bar".  Then the program pulls its plug.  Trust me,  
this DOES occur :-)

What _does_ happen is that messages to nil objects are a no-op.  Nothing  
happens, and the program just continues execution. Perhaps that was his  
problem.

--
Don McGregor             | California danger signs: you own more pairs of 
mcgredo@bluto.ie.orst.edu| shorts than you do long pants.
Xref: sparky comp.object:1755 comp.lang.misc:1715 comp.lang.functional:483
From: stephen@estragon.uchicago.edu (Stephen P Spackman)
Newsgroups: comp.object,comp.lang.misc,comp.lang.functional
Subject: Re: Types as first-class values?
Date: 15 Apr 92 06:57:13 GMT
Organization: University of Chicago CILS

In article <nmyjmaf.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
|In article <STEPHEN.92Apr14174618@estragon.uchicago.edu> stephen@estragon.uchicago.edu (Stephen P Spackman) writes:
|>In article <7597@cui.unige.ch> oscar@cui.unige.ch (Oscar Nierstrasz) writes:
|>>  2. test whether a value satisfies it (and, if it does, be able to use that
|>>     value in a type-safe way within the scope of the test),
|>I'm a little confused by the notion of type you are looking for: the
|>fact that you specify that you want a membership TEST suggests that
|>you're thinking of a set theory rather than a type theory at all -
|>types are properties of the expressions, not the values, *even when
|>the types are values themselves*.
|
|If by value he means object in the OO paradigm, this makes perfect sense as
|in Modula-3's typecase statement.  So, a construct should be able to
|determine if an object is a member or instance of some class, and if so,
|perhaps interact with that object in a statically typed (safe and efficient)
|way.

But those aren't types in the technical sense. Nor are they sets.
Types lack dynamic membership test (or rather, it can in principle be
resolved statically), and sets permit something to belong to multiple
sets arbitrarily.

|>Languages that provide first-class sets? I can't think of any; in
|>fact, I'm not sure how you could do that. Unless you restricted
|>yourself to small finite sets a la SETL, most of your primitives would
|>be too expensive (the advantage of the type-theoretic approach is that
|>while compilation may fail to terminate unexpectedly, a successfully
|>compiled programme won't misbehave in that way).
|
|Since set operations are quite small (add, delete, includes, ...), I don't
|see what is so difficult, almost any representation seems to suffice and
|if you need a set, you'll have to incur the expense anyway.  But I do agree
|that small simple sets (if not all sets) should be implemented as
|efficiently as possible whether provided by a programming language (Pascal,
|Modula) or library (Smalltalk).

But one of the required operations is membership test! What algorithm
do you propose to check if some function is in some set? That's why
you need types in the type theory sense: they don't barf on functions
considered as objects.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------
Newsgroups: comp.object
From: zen@csl.dl.nec.com (zen kishimoto)
Subject: objectmaker and objectery
Summary: Has anyone used them?
Keywords: objectmaker objectery
Organization: NEC America, C & C Software Development Laboratory
Date: 17 Apr 92 01:27:54 GMT

I would like to hear from those who used ObjectMaker and/or Objectry.
Basically, we would like to see if it is worth investing on them.
Any information is appreciated.

Zen Kishimoto (zen@csl.dl.nec.com)
-- 
-----------------------------------------------------------------
Zen Kishimoto          C&C Software Development Laboratory
	       NEC America, Inc.
		       1901 Gateway Dr. Irving, Texas 75038
Newsgroups: comp.object
From: "Bob Hathaway" <objsys@netcom.com>
Subject: Re: Scanner, Parser Generator Critique
Date: Tue, 07 Apr 92 03:44:42 GMT
Organization: Object Systems

In article <MARKF.92Apr3114645@montreux.ai.mit.edu> markf@zurich.ai.mit.edu writes:
>  I still think that some of the posters to this thread think that
>funtional programming just means using an applicative style. What
>really distinguishes functional programming is the use of higher order
>functions (i.e. functions that accept functions as arguments and
>return functions).

  I wonder if he means me...

>
>-Mark
>

Does this include C's function pointers and Modula's procedural variables
and Ada's subprogram values (or even generic subprogram parameters) and etc.?

bob
objsys@netcom.com
From: roelw@cs.vu.nl (Roel J Wieringa)
Newsgroups: comp.object
Subject: Re: Object-oriented analysis (general query)
Date: 7 Apr 92 08:06:46 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <1992Apr3.180413.2731@colorado.edu> scotth@sigi.cs.colorado.edu (Scott Henninger) writes:
>Could someone give me a concise explanation of the difference between
>object-oriented *analysis* and structured analysis methods?
>

They use a different modularization principle. Processes (data
transformations, ``bubbles'') in SA have officially no local memory, they
just transform input into output every time they are called. Objects have a
local memory and local events which may update the memory. 

The difference is not absolute though. A data transformation at a top level
in a leveled set of DFD's is ``implemented'' in lower level DFD's that may
contain data stores, i.e. memory. Data transformations at the top level of a
set of leveled DFD's tend to look like objects. At the lowest level, they
are primitive, memory-less data transformations and they look very much like
local events in the life of an object.

>What are some good references for object-oriented analysis?

You might want to look in directory roelw in ftp site star.cs.vu.nl (login
as anonymous). There is a paper ooa.ps.Z in there that contains some
references. The paper itself illustrates what I just said by transforming a
DFD into an OO model. Look into the 00README file for an explanation of the
contents of the files.


Roel
Xref: sparky comp.object:1785 comp.lang.c++:6883 comp.lang.smalltalk:977
From: slewis@cbnewsm.cb.att.com (scott.b.lewis)
Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk
Subject: Request for OO success and failure stories
Keywords: OOA OOD OOP
Date: 17 Apr 92 14:46:49 GMT
Followup-To: comp.object
Distribution: usa
Organization: AT&T


I would like some help finding information (pub papers or other) on the
"success" or "failure" of OOA, OOD and OOP for large commercial 
software projects.  The more detailed information (e.g. metrics on
initial development and reuse, comparisons with alternative analysis
and programming approaches, etc) the better.  

We would like to get a better handle on the advantages/disadvantages 
of OO for software development and use this info to make a case for
mgmt buy-in for the use of OO (assuming, of course, that the data
favor that position :-) ).

Can anyone provide some good pointers?  Please reply via email to
slewis@hound.att.com

Thanksinadvance,
 
Scott Lewis 

 
Xref: sparky comp.object:1767 comp.lang.misc:1727 comp.lang.functional:491
From: yali@bnr.ca (Yawar Ali)
Subject: Re: O-O adoption, rejection
Reply-To: yali@bnr.ca (Yawar Ali)
Organization: Bell-Northern Research, Ottawa, Ontario, CANADA
Date: Wed, 8 Apr 92 18:04:09 GMT


In article <1992Apr6.150855.228@hpb.hwc.ca>, inunn@hpb.hwc.ca writes:
|> I recall hearing that Cognos Inc. in Ottawa, Canada had a large OO develop-
|> ment project which they had to scrap.  Confirmation and reasons for should
|> be sought after before using this information.
|> 
|> Ian Nunn

There was an article by Dr. Burton Leathers of Cognos on their experience
with OO development using Eiffel, analyzing what went wrong and why. This 
appeared in HOOT, v.1, no. 9, July 1990. The gist of the article was that
the project failed because it was too ambitious for a pilot project
in OO development, they followed a traditional development process (no early prototyping), the project was not managed properly, the technology was oversold to senior managment, and there were performance problems with the technology. 


--- 
Yawar Ali  				
Bell-Northern Research				EMail: yali@bnr.ca
Ottawa, Ontario, Canada				(613-)763-7741
--------Standard Disclaimer: BNR is not responsible for my opinions--------
--
Yawar Ali  				
Bell-Northern Research				EMail: yali@bnr.ca
Ottawa, Ontario, Canada				(613-)763-7741
--------Standard Disclaimer: BNR is not responsible for my opinions--------
Newsgroups: comp.object
From: axel@cs.tu-berlin.de (Axel Mahler)
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Organization: /home/stone/axel/.organization
	<1992Apr8.060832.9260@sfc.sony.com> <jctic0k@fido.asd.sgi.com>
Date: Tue, 14 Apr 1992 19:04:57 GMT

In article <jctic0k@fido.asd.sgi.com> linton@marktwain.rad.sgi.com (Mark Linton) writes:
   In article <1992Apr8.060832.9260@sfc.sony.com>, berger@sfc.sony.com (Bob Berger) writes:
   |> My goal here is not so much to praise NeXT. But to remind all of us
   |> C++ / X folks that we are not living up to the promise of the OO
   |> paradigm. The current C++ / X environments are not making it that much
   |> easier to stand on the shoulders of people who have done the
   |> foundation work. We still keep finding ourselves reinventing the
   |> wheel, starting each project from first principles.

   I agree and disagree.  C++ programming environments
   are disappointing, but with respect to building applications
   we are much better off today with glyphs and Unidraw than we were
   several years ago.

J. Ousterhout claims that C++, object-oriented toolkits are the wrong
solution to the problem of easing the development of nice UIs. The
Tcl/Tk toolkit that he developed appears to be an exceptionally
strong argument for his claim. One of Ousterhout's arguments is that
composition rather than inheritance should be used as the principal
UI design technique.

Axel Mahler, TU Berlin
--
===============================================================================
Axel Mahler, Tech.Univ. Berlin
E-Mail: axel@cs.tu-berlin.de (axel@db0tui62.bitnet)
Voice: +49-30-314-73487
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Scanner, Parser Generator Critique
Date: Thu, 09 Apr 92 02:13:39 GMT
Organization: Object Systems

In article <MDAY.92Apr7110717@jukebox.lcs.mit.edu> mday@jukebox.lcs.mit.edu (Mark Day) writes:
> "Bob Hathaway" <objsys@netcom.com> writes:
> > markf@zurich.ai.mit.edu writes:
> >                                                             What
> >really distinguishes functional programming is the use of higher order
> >functions (i.e. functions that accept functions as arguments and
> >return functions).
>
> Does this include C's function pointers and Modula's procedural variables
> and Ada's subprogram values (or even generic subprogram parameters) and etc.?
>
>No.

Why not?

>Why is this thread in comp.object?

Because I like OO (and because there's a very formal classical CS person
out yonder...).

bob
objsys@netcom.com
Xref: sparky comp.object:1762 eunet.misc:304
From: jlk@daimi.aau.dk (Jorgen Lindskov Knudsen)
Newsgroups: comp.object,dk.general,nordunet.general,eunet.misc
Subject: call-for-participation
Date: 13 Apr 92 12:13:26 GMT
Reply-To: jlknudsen@daimi.aau.dk (Jorgen Lindskov Knudsen)
Distribution: eunet
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark

----- INVITATION ----- CALL FOR PARTICIPATION ----- INVITATION -----
				  
	    Mjolner Seminar 20-21 Maj 1992 in Stockholm:
				  
      OBJECT-ORIENTED DESIGN, IMPLEMENTATION and ENVIRONMENTS
				  

The Nordic Mjolner project is happy to invite you to a seminar on
issues within object-orientation.  The seminar will present the most
important results of the Nordic Mjolner Project.

Highlights:  Object-Oriented Programming
             Object-Oriented DataBases
             Object-Oriented Software Development Environments
             Object-Oriented Analysis & Design
             and advanced research results like 
                 Incremental Compilation

Invited Speakers:  Professor Kristen Nygaard, University of Oslo
                   Professor Stan Zdonik, Brown University

Mjolner speakers:
     Professor Ole Lehrmann Madsen, Aarhus University
     Assoc. professor Boris Magnusson, Lund Institute of Technology
     Assoc. professor Jorgen Lindskov Knudsen, Aarhus University
     and other researcher in special fields

For more information please contact:

               Mjolner Secretariate
               c/o Technoconsult
               Sortedam Dossering 19
               DK-2200 Copenhagen N
               Denmark

               E-mail:     Techno@login.dkuug.dk
               Telefax:    +45 31 35 23 27
               (Telephone: +45 35 37 34 09)

We need your registration no later than the 27'th of April.

The Mjolner project has been carried out by Nokia
Telecommunications, Mjolner Informatics, ABB Corporate Research,
Telia Research, Aarhus University and Lund University/Institute of
Technology. The project has got financial support by Nordisk
Industrifond and national research boards (STU/NUTEK and TEKES).



--

   Jorgen Lindskov Knudsen, Computer Science Department, Aarhus University
   Ny Munkegade 116, DK-8000 Aarhus C, DENMARK
   E-mail: jlknudsen@daimi.aau.dk, Phone: +45 86 12 71 88, Fax: +45 86 13 57 25
From: eric@tfs.com (Eric Smith)
Newsgroups: comp.object
Subject: Re: Encapsulation & Information Hiding....
Date: 6 Apr 92 15:51:40 GMT
Article-I.D.: tfs.1992Apr6.155140.3302
Organization: TFS

In article <1992Apr5.164955.28988@aber.ac.uk> aro@aber.ac.uk (Andrew Ormsby) writes:
>as this example, is almost enough to give information hiding a bad
>name.  Far better, surely, to have  a "hidden" attribute for a file, as
>the Macintosh does?
>
>I'm forced to admit, of course, that you can have information hiding
>without encapsulation. But I'm far from convinced that it is useful
>on its own. 


The "." files are not a correct example of information hiding.  The
important feature of information hiding is that it can be enforced,
such that you can use it to prove that the hidden information is not
depended on, so you can change it without worrying about affecting
other software.

A much better example would be to use the permission bits of your
directory entries to make the information unreadable.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.object
Subject: Re: SUMMARY: Object-Oriented Software Maintenance (1200 lines)
Date: 8 Apr 92 09:06:49 GMT
	<sqpjtsf.objsys@netcom.com> <9qpjhng.objsys@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: objsys@netcom.com's message of 7 Apr 92 04:46:14 GMT

In article <9qpjhng.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
   >In article <BEVAN.92Apr3165546@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
   >>Lumping "dynamic typing" in with "weak typing"/"typless" means you

   Like it or not, the literature refers to purely dynamically typed languages
   (such as Smalltalk) as typeless

What literature?  I've read a fair few "OO" books, and I'm not
particularly happy with the terminology used therein, as I mentioned
in my previous message.  I specifically don't like any definition that
cannot distinguish between FORTH and Smalltalk.  If the "literature"
above can't do that, then _I_ wouldn't recommend that literature (at
least on on that topic), no matter who wrote it.

bevan
Newsgroups: comp.object
From: VALLHON@ricevm1.rice.edu (VALLHONRAT, S V)
Subject: Object-Oriented Design Course Offered
Organization: Rice University, Houston, TX
Date: Thu, 9 Apr 1992 16:08:01 GMT

Rice University's Office of Continuing Studies is offering a three day course
on Object-Oriented Analysis, Modeling, and Design from June 1 - 3, 1992 in
Houston, Texas.  The fee for this course is $595.  For more information call
(713) 527-4803 or (713) 520-6022.
From: laub@Software.Mitel.COM (Boniface Lau)
Newsgroups: comp.object
Subject: Re: SUMMARY: complexity in O-O
Date: 12 Apr 92 17:36:42 GMT
Organization: Mitel. Kanata (Ontario). Canada.
In-reply-to: johnson@m.cs.uiuc.edu's message of 10 Apr 92 03:35:27 GMT

>>>>> On 10 Apr 92 03:35:27 GMT, johnson@m.cs.uiuc.edu (Ralph Johnson) said:

Ralph> >What is Software Complexity?

Ralph> >Software Complexity is difficulty to maintain, change and
Ralph> >understand programs.  It deals with the psychological
Ralph> >complexity of programs.

Ralph> >What are best known complexity measures?

Ralph> >Some of the best known complexity measures are Measure of
Ralph> >McCabe (Cyclomatic number), Lines of Code (LOC) and the
Ralph> >Measures of Halstead (Length, Volume, Difficulty and Effort).

Ralph> This is a very interesting posting because of the juxtoposition
Ralph> of these two questions.  Suppose you wanted to measure how
Ralph> difficult it is to maintain, change, and understand programs.
Ralph> What kind of measure would you use?  Wouldn't you measure how
Ralph> long it took to enhance and change a program, and how long it
Ralph> took before people could accurately answer questions about it?
Ralph> It seems to me that the ONLY good complexity measures are those
Ralph> measure PEOPLE working with PROGRAMS, not those that measure
Ralph> some syntactic aspect of the program.  In other words, the
Ralph> "best known" complexity measures are all junk.  They are
Ralph> worthless garbage, they are useless trivia, they are a waste of
Ralph> time.  We should not be interested in syntactic measures of a
Ralph> program unless someone has shown that it has a strong
Ralph> correlation to maintainability, changeability, and ease of
Ralph> understanding.

While Halstead's metrics showed that Halstead was ignorant on what was
known about human cognition at the time, Lines of Code and McCabe do
make some senses.

Each of the metrics (McCabe, Lines of Code, Halstead) focused on a
particular aspect of program development.  I would say most of the
problems with the metrics are due to the fact that people were trying
to use them to measure the overall program development.  As long as
people understand that program development are affected by many
factors, they will stop putting unrealistic expectation on any single
metric.  With that understanding, they can use individual metric to
help them monitor specific factor. As to the interaction of factors,
much of the them have to do with the development environment.


--
Boniface Lau    (613) 592-2122 ext. 3042    Boniface_Lau@Mitel.COM
Mitel Corp.  				    
350 Legget Drive, Kanata
Ontario, Canada, K2K 1X3
Newsgroups: comp.object
From: conrozi@kk188.ericsson.se (Roman Zielinski TT/TSM)
Newsgroups: comp.object
Subject: Re: OOA TOOL for Windows3
Date: 9 Apr 92 10:25:57 GMT
Organization: Ericsson

knox@spruce.gsfc.nasa.gov (Robert Knox) writes:

>Windows 3.1 is now available retail, and I gleefully bought a 
>copy last night.  Then today I used ftp to pick up a copy of 
>the OO Documentation Tool developed by Roman Zielinski, in 
>this case stored in oot-1-03.zip (either on garbo.uwasa.fi or 
>the SIMTEL server at White Sands, NM).  Everything seemed to 
>transfer and unpack without a hitch.  I followed the simple 
>installation instructions . . . and ...

>Imagine my disappointment when the application comes up in
>its own window with scroll bars and a label across the top, 
>but does nada, no menu, nothing.  Except, well the right mouse 
>button brings up the outline of a rectangle which disapears 
>when you release it.  This gets dull after a few tries.
>...................... lines cut away .....

Yes, you right, my OO Doc Tool does not work under win 3.1. (I mentioned
it in the winhelp file you cannot invoke from the tool because you do not 
have access to menus by a strange win3.1-reason).

It seems to be a kind of MS Windows 3.0 -> 3.1 incompatibility somewhere.

Fortunately I've got today win3.1, so I will during the weekend try out
what is wrong and find a way around (if I can find a soulution without 
debugger, because Borland's tdw/2.0-3.0 does not work under win3.1 either... 
(it's not only me who have problems with win3.1, btw there is at least
10-20 popular comersial programs that need to be upgraded to 3.1 level! -;)

----------------------------------------------------------------------------
I will send a news to cbip and comp.object when I have a solution available.
Give me some more days (I had no chance to use win3.1 beta).
----------------------------------------------------------------------------

Regards,
Roman Zielinski


>- Bob Knox
>- Biospheric Sciences Branch, Code 923.0
>- NASA/Goddard Space Flight Center, Greenbelt, MD 20771 
>- knox@spruce.gsfc.nasa.gov      | BITNET: knox@ricevm1
From: boelhouw@wsooti06.info.win.tue.nl (Erik Boelhouwer)
Newsgroups: comp.lang.eiffel
Subject: Error :  size > BLOCK_SIZE
Date: 10 Apr 92 08:50:10 GMT
Reply-To: boelhouw@info.win.tue.nl

Recently, I compiled an Eiffel class and encountered the error :

pass4 : class "pat_mon_int" 
        space_alloc : size > BLOCK_SIZE

Sometimes this occurred when pass2 did not terminate, and recompilation
started with pass3.
For slightly different programs , pass2 also not terminated , but restarting
the compilation, C-code was generated.

Can anybody give me some information about this error, and also some more
information about "pass2".

Please send information to :

Erik Boelhouwer
T.U. Eindhoven
The Netherlands
e-mail  :  boelhouw@info.win.tue.nl
From: gt0460d@prism.gatech.EDU (DSOUZA,ROSARIO JOHN)
Newsgroups: comp.lang.eiffel
Subject: Lexing and Parsing using the Eiffel Libraries
Date: 6 Apr 92 17:26:30 GMT
Organization: Georgia Institute of Technology


Hi,

Has anyone had any experience using the Eiffel Libraries for building
lexical analyzers and parsers - for a full-size programming language?

I am thinking of using the Eiffel Libraries for building a parser (not
a compiler) for Eiffel (version 2.3). Comments, suggestions, experiences
are welcome.

..Ross D'Souza
ross@cc.gatech.edu
Newsgroups: comp.lang.eiffel