HDTenEightyP/NetNews huggingface dataset:
From: paul@allink.com (paul reiber)
Subject: Re: LOOKING FOR: a good unix DOMF...
Organization: NYNEX ALLINK Company
Date: Fri, 2 Oct 1992 23:48:35 GMT

I've learned (what else is new) I've used an incorrect
term in asking that question.

The term was DOMF, which was used generally, and not specifically
in reference to on-going efforts in the DOMF field.

I was looking for, and have found, the OODB I was describing,
and it meets all those requirements and more.

Thank you, Internet Dwellers! :-)

-Paul
-- 
 +---------------------+------------------------+-----------------------------+
 | Paul B. Reiber, Jr. | NYNEX Allink Company   | "To Invent, you need a good |
 |  (914)  644 - 7729  | 4 Gannett Drive,       |  Imagination and a Pile of  |
 |   paul@allink.com   | White Plains, NY 10604 |  Junk."     - Thomas Edison |
Newsgroups: comp.object
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: Tue, 6 Oct 1992 19:07:29 GMT

In article <1992Oct6.003602.21078@beaver.cs.washington.edu> chambers@cs.washington.edu writes:
>In article <TMB.92Oct4182305@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
>|> OO-style polymorphism is more restrictive than Milner-style
>|> polymorphism, and also too restrictive for my tastes in the presence
>|> of a static type checker.
>
>Ad hoc ("OO-style") polymorphism is not more restrictive than
>parametric ("Milner-style") polymorphism; the two are incomparable in
>expressive power.  Certainly things like arrays of mixed integers,
>rationals, and floats cannot be statically-typed in ML.  

	Its very difficult for me to see how you can use
an array of polymorphic numbers to *do* anything. I dont
believe numbers can be characterised as "OO-style" objects.

	For example, to test if such an array is sorted,
you need a comparison routine. One way to write such a
routine is to convert each number to a fixed predefined
numeric type (say double float), and this method
is indeed polymorphic (that is, the conversion routine is).

	I dont believe it can be done without the predefined
universal numeric type. Of course, if you fix in advance
the number classes to say Integer, Rational, Float, then you can
write 9 comparison routines to do the job and dispatch
to the correct one, but this isnt polymorphism in my books,
or rather, it isnt object oriented. The reason of course
is that to add a new type Double you have to know the types
you already have---they are coupled when OO requires
each type be self-contained (encapsulated).

>
>Your comments on some of the things that SML's functors can do (e.g.
>the group/field example) are tasty food for thought, though.
>

	OO is not a complete solution. It handles only attributes
properly, and very few ADTs can be characterised with only attributes.
SML module system really does look like a major advance here.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: comparing object-oriented platforms
Organization: WEITEK Corporation, Sunnyvale CA
Date: Fri, 2 Oct 92 00:40:28 GMT

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.

Amen. That's why I note that the caching is faster than complete interpreta-
tion, but is still slower. And that and the size make it unusable for
what I am trying to do.

>IMHO the cache scheme of Parc may be overblown as a real world speed up.
>It will depend on the application.

Yep.

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

Yep. I'd also like to see some easy look and feel kits so that smalltalk
applications could look 'native.'
 
>	Craig
>
>-- 
>Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
>Productivity Group POB 60458 Sunnyvale, CA  94088


-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.object
Subject: Re: comparing object-oriented platforms
Date: 3 Oct 92 09:35:00 GMT
	<TMB.92Oct1180516@arolla.idiap.ch>
	<1992Oct2.044313.14910@actrix.gen.nz>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: Des.Kenny@bbs.actrix.gen.nz's message of 2 Oct 92 04:43:13 GMT

In article <1992Oct2.044313.14910@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:

   In article <TMB.92Oct1180516@arolla.idiap.ch> tmb@idiap.ch writes:
   > What you are arguing for is opacity. Opacity can be achieved in many
   > programming languages, including C and C++, without even ever using
   > any OO techniques. That is, you can define a datatype in C/C++ such
   > that you are guaranteed that no user of that datatype manipulates it
   > without going through the interface that has been provided by the
   > author of the datatype.

     Yes I agree you CAN in many languages, some more easily than
     others.  The difference between C++ and Eiffel is in Eiffel you
     MUST protect an object's state by its methods. [...]  BUT the
     assumption that all programmers in industry are so well
     disciplined is sadly just not true.

If I design the interface to my class, I can keep others from messing
around with its internals in both C++ and Eiffel. But if someone wants
to expose the internal representation of an object, he can do so in
any language, simply by providing the "wrong" methods. Eiffel may
encourage better programming styles, but it can't enforce them.

					Thomas.

PS: Note that even in C++, you _can_ usually make data members
"active" without having to modify the user.

Newsgroups: comp.object
From: mjb@netcom.com (Martin Brown)
Subject: Re: Object-Oriented Prolog
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Tue, 6 Oct 1992 06:47:48 GMT

In article <1aph9mINNl73@coral.bucknell.edu> cwalker@elnath.bucknell.edu (carleton walker `93) writes:
>In article <1apgerINNl2f@coral.bucknell.edu> cwalker@elnath.bucknell.edu (carleton walker `93) writes:
>>
>	Sorry about this.
>	Does anyone know of an object-oriented Prolog? If so, does
>the implementation meet Booch's criteria for an object-oriented
>programming language?
>
>
>--
>Carl Walker				"Hectic days ahead of us,
>Bucknell University			 Rotten ones behind,
>Lewisburg, PA				 Keeping plastics in our pockets,
>cwalker@canopus.bucknell.edu (! tmc.edu) Children never mind." - K, S, & W

For Digitalk's V/286 smalltalk there is a separate "Goodies" pack that contains
Prolog classes.  I'm not a prolog user, so I can't say how robust the classes
are.  Also, somebody did convert the classes to Digitalk's V/Windows product,
but again, I can't say how good the resulting classes are.

-- 

                                   - mjb -

                                mjb@netcom.com
From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Newsgroups: comp.object
Subject: Q's on OO systems..
Date: 2 Oct 1992 12:58:48 +0800
Organization: Home
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: TIN [version 1.1 PL6]


Hi. I am writing a persistent, concurrent, strongly typed OO system,
and have a (another) niggling little problem.

If you have tree classes A, B and C. A inherits B and C.
(i.e. A is a sub-type of both B and C).
Then an instance of A gets passes as a parameter to a function f that
arguments of type C. The question is, what should get passed????

My object structure is currently just
	typedef struct object {
		int tag; /* The class of the object */
		struct object *o[0];
		} Object;

Where the array o is as long as the number of attributes the class
has. Now the function f is expecting to get a pointer to some
structure like the above. (i.e. and object handle). So should A look
like....
	{
	int tag = class_of(A);
	{
		int tag = class_of(B);
		Object *bs_first_attrib;
		Object *bs_second_attrib;
		...
	}
	{
		int tag class_of(C);
		Object *cs_first_attrib;
		Object *cs_second_attrib;
		..
	}
Or what?? The above solution is a possible one. But it has the
drawbacks of requiring a tag for every inherited class that has an
attribute. This is not good (tm).

I thought about discarding tags (as it is strongly typed), but then
how do I get around problems like..
	B has a method M.
	A inherits B and re-defines M.
	An instance of A gets passed to f. f calls M on the object of
A, which has been temporarily type cast to be B. How does f know which
method to use???


Any ideas??? 

Michael
From: cwalker@elnath.bucknell.edu (carleton walker `93)
Newsgroups: comp.object
Subject: Re: Object-Oriented Prolog
Date: 5 Oct 1992 13:51:50 GMT
Organization: Bucknell University, Lewisburg, PA
NNTP-Posting-Host: elnath.cs.bucknell.edu

In article <1apgerINNl2f@coral.bucknell.edu> cwalker@elnath.bucknell.edu (carleton walker `93) writes:
>
	Sorry about this.
	Does anyone know of an object-oriented Prolog? If so, does
the implementation meet Booch's criteria for an object-oriented
programming language?


--
Carl Walker				"Hectic days ahead of us,
Bucknell University			 Rotten ones behind,
Lewisburg, PA				 Keeping plastics in our pockets,
cwalker@canopus.bucknell.edu (! tmc.edu) Children never mind." - K, S, & W
Xref: sparky comp.object:3775 comp.lang.smalltalk:1967 comp.lang.eiffel:1193
From: paj@uk.co.gec-mrc (Paul Johnson)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 29 Sep 92 07:58:27 GMT
Reply-To: paj@uk.co.gec-mrc (Paul Johnson)
Organization: GEC-Marconi Research Centre, Great Baddow, UK

In article <23741@alice.att.com> garry@alice.UUCP () writes:

>[ Many lines of Eiffel cheerleading,
>  including lots of interesting technical aspects, deleted ]

[...]

>Then you lay the following crap on me. ... Many of the "discussions"
>of C++ vs. Eiffel I've seen in the past showed the same kind of
>wild-eyed enthusiasm for Eiffel, mixed with disdain for the lowly
>cretins who would debase themselves by using C++. ....

[ Quotes asserting C++ is not real OO and refutations by Garry ]


Hold on everyone.  PLEASE lets not have a language war.

For everyone's information, I learned C at University, did a large
project in C++ (including multitasking) and am now a wild-eyed Eiffel
enthusiast.  However I do not write off C++ for OO programming.  You
CAN write OO programs in C++.  Some C++ programmers do this, others
don't.

You can also write spaghetti code in Eiffel.  "A Real Programmer can
write Fortran in any language."

Can everyone please accept that all languages have pros and cons?
Some are language issues, others are mucky real-world issues.  Lets
just leave it there.

Paul.

-- 
Paul Johnson (paj@gec-mrc.co.uk).	    | Tel: +44 245 73331 ext 3245
--------------------------------------------+----------------------------------
These ideas and others like them can be had | GEC-Marconi Research is not
for $0.02 each from any reputable idealist. | responsible for my opinions
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Passing functions as parameters in an OO environment
Date: Sun, 27 Sep 92 05:22:19 GMT
Organization: Object Systems

In article <oejtwni00aw6A_yVAe@andrew.cmu.edu> sm86+@andrew.cmu.edu (Stefan Monnier) writes:
>Excerpts from netnews.comp.object: 22-Sep-92 Re: Passing functions as
>pa.. Lars Buettner@cs.tu-berl (1457)
>
>> I believe you would violate an OO language with this solution.
>> Passing a function to a method (i.e., a function inside of a class)
>> wouldn't very useful.
>> Try following :
>> Assuming there is a class called SORT which is defined something like this
>
>> class SORT : SORTABLE  {
>> 	// some private constants and the like
>> 	int compare(SORTABLE& element1, SORTABLE& element2); virtual;
>> 	int sort();
>> 	SORT();
>> 	~SORT();
>> 	void output( /* parameterlist */ ); // or any other method to get the
>> sorted result
>> };
>
>> Class SORTABLE implements the datastruture to be sorted and could be of
>> generic type.
>
>> Keep an eye on the virtual declaration of method compare(). This allows you to
>> build a class that inherits from SORT in which you can redefine this
>> method in an
>> appropriate manner.
>> (I'm not sure about the syntax of C++, but the principle should be obvious.)
>
>> Hope this helps and sorry for my pidguin English.      Lars
>
>> email: larsbuet@cs.tu-berlin.de
>
>
>I personnaly miss this kind of feature in OOL !
>I know it's not that easy to integrate in a true OOL, but...
>
>Your example is typical: sure, I can define a new subclass,
>but what if I want my friends-list sorted by weight once
>and by age ? Do I have to I have to 'transpose' all my
>friends from a class to another ?
>
>Workaround generally exist, but they still are workaround !
>
>Definitely, function- or method-variables are useful, 
>and OO is not an excuse !

Please excuse my interjection but this approach reminds me of Smalltalk's
LinkedLists (as opposed to OrderedCollections).  You must derive your class
from SORTABLE above and from LINK in Smalltalk.  This is just inconvenient
for new classes but may not even be possible for existing (non-modifyable)
classes (and without MI its even worse).  Its not hard to come up with better
solutions (perhaps with generics) and thats in my better judgement.

bob
objsyss@netcom.com
From: seanm@cpg.trs.reuter.com (Sean M. McCarthy)
Newsgroups: comp.object
Subject: Re: Looking for Ptech Information
Date: 5 Oct 92 14:11:42 GMT
Organization: Reuters Client Site Systems, Oakbrook,IL

In article <2927028382.0.p00058@psilink.com> p00058@psilink.com (Ronald C. Schultz) writes:
>I am looking for information on a tool named Ptech which I believe is an 
>OO CASE tool which is supposed to support the Martin and Odell method.  
>Does anyone know of this product and a point of contact?
>
>------------------------------------------------------------------------------
>Ron Schultz 
>Berard Software Engineering, Inc.
>Columbus, Ohio Office                   Headquarters
>5634 Claire Court                       101 Lakeforest Blvd.
>Dublin, Ohio 43017-2440                 Gaithersburg, Md.  20877
>(614) 798-0295 Phone                    (301) 417-9884 Phone
>(614) 798-0296 FAX                      (301) 417-0021 FAX
>ron@bse.com                             info@bse.com
>------------------------------------------------------------------------------

Quoting from their literature, Ptech is an OO information analysis and
design tool which:

"supports integrated function, process, and data modeling and design
specification; provides a graphical user interface interlocked with
an active database; and, includes direct application code generation."

It should be available on Sun, DEC, and SGI platforms at least.

The latest contact I have (as of January) for Ptech is:

Louis Reagan
Associative Design Technology
Two Westborough Business Park
Westborough, MA 01581-3199

tel: (508) 366-9166
fax: (508) 366-3983 
--

	Sean McCarthy
	email: seanm@richsun.cpg.trs.reuter.com
From: fhd@panix.com (Frank Deutschmann)
Newsgroups: comp.object
Subject: Re: Object-Oriented Prolog
Date: 5 Oct 92 18:46:53 GMT
Organization: PANIX Public Access Unix & Internet, NYC


I know of two OO "wrappers" for Prolog:
	ProTalk, distributed with the Quintus Prolog system; I looked
at this briefly, but it just got too confusing
	Logic and Objects, part of the IC Prolog ][ distribution, but
also available for Mac Prolog; currently looking at this.

From the L&O distribution:
A brief documentation for L&O is included in the IC PROLOG ][ manual.
For a
detailed description of the language, refer to the book:

        F.G.MCCabe
        LOGIC & OBJECTS
        Prentice Hall International, 1992.

For comments, bugs etc, please send email to:

        zb@doc.ic.ac.uk (Zacharias Bobolakis)

        Logic Programming Section
        Dept of Computing
        Imperial College
        London

----------------

I read the L&O book, and thought it very useful; the language seems to
be a very good merging of OO and Prolog ideas. However, the
incorporation of functional items is not-so-hot to me (because of
potential proveability problems)...

-- 
-frank
(fhd@panix.com)
Xref: sparky comp.object:3783 comp.lang.smalltalk:1976 comp.lang.eiffel:1198
From: sailer@cup.portal.com (Lee Douglas Sailer)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: Simula info (LONG) Was(Re: comparing object-oriented platfo
Date: Tue, 29 Sep 92 20:24:35 PDT
Organization: The Portal System (TM)
  <+s_p3w=.nagle@netcom.com><23741@alice.att.com>
  <1992Sep29.043418.16848@actrix.gen.nz><1a932eINNea4@corax.udac.uu.se>
  <KNUTO.92Sep29114902@katnosa.ifi.uio.no>

Thanks for that description of Simula.  I remember fondly the many years
I programmed in Simula during the late 70s and early 80s.

I want to add one important point.  While it is true that Simula offers classes
and objects, they are used in somewhat different ways than you might be
used to in C++, smalltalk, or one of the better OO languages 8-)

For example the Simset "class" is really more like a language extension.
If you "inherit" it, you get access to a number of features that aren't in
the base language.
 
The "quasi parallel" features are also very interesting.  A method can
deactivate itself in the middle of a computation, and then be reactivated later
if the rest of the calulations are needed.  Some might call Simula an Actor
language rather than an OO language.
Xref: sparky comp.object:3793 comp.lang.smalltalk:1982 comp.lang.eiffel:1202
From: khaw@parcplace.com (Mike Khaw)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
Date: 30 Sep 92 15:52:36 GMT

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. In general, this is a significant
win because empirical observation shows that methods once called tend
to be called again.  In addition, bytecode is a much more compact
representation than native machine code (approx. 5-10 times, depending on
whether the processor is CISC or RISC), so keeping the bulk of the
system as bytecodes significantly reduces demands on memory.
Additionally, bytecodes are machine independent, so running Smalltalk
images can be saved to disk and moved to different platforms and
launched w/o explicit recompilation; i.e., ParcPlace Smalltalk images
are binary portable among platforms.

Now, I'm not saying that this makes Smalltalk faster than Eiffel.
I haven't used Eiffel, so I have nothing to say about comparing the
performance of the 2.

>  So you can use Smalltalk for industrial applications but you are taking
>  very big risks. Most businesses like to minimise their exposure to risk
>  if they want to stay in business. Of course , this is an individual
>  judgement.

Gee, I guess ParcPlace's customers, which includes large corporations,
either are big risk takers or else they find Smalltalk to be adequately
safe.

--
Michael Khaw	Domain=khaw@parcplace.com, UUCP=...!uunet!parcplace!khaw
ParcPlace Systems, Sunnyvale, CA	PRODUCT INFO: info@parcplace.com
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: determine a class as Blocking or Active,
Date: Sun, 27 Sep 92 06:52:35 GMT
Organization: Object Systems

In article <2AC2446E.11846@ics.uci.edu> song@ics.uci.edu (Xiping Song) writes:
>-------------
>Hi,
>  I am using Booch class and operation templates to design a software.
>I found that I cannot readily determine a class as being BLOCKING or
>ACTIVE.

Blocking classes define passive objects.  They execute code on behalf of
other active objects or threads.  An example is a passive monitor.  They
can be provided as a programming language construct or can be built
explicitly with semaphores (Ada).  Ada monitors (tasks) are active objects/
monitors because they possess a thread of control and shared variables are
implicilty blocking objects.

>        Similarly, I cannot easily determine an operation as GUARDED

Guarded sounds like Ada's guards (when clauses) on accept statements.

>or SYNCHRONOUS. These are concurrent types defined in Booch's book and
>his new paper.

Ada's standard entry calls are synchronous (both parties must be ready).
Balking is Ada's conditional entry call and Timeout is Ada's timed entry
call.  Asynchronous is not avialable in Ada; try ConcurrentC (its treated
like an exception, grab the active objects attention even if its not
waiting at a select or accept statement.  [Hey, I didn't even need to look
to remember my old Ada terminology!-]

Hope this helps,
bob
objsys@netcom.com
Xref: sparky comp.object:3795 comp.lang.smalltalk:1984 comp.lang.eiffel:1203