HDTenEightyP/NetNews huggingface dataset:
From: tek@pram.cs.ucla.edu (Ted Kim, Random Dude)
Subject: Sun IDL front-end?
Organization: UCLA Computer Science Department
Date: Wed, 2 Sep 92 17:18:45 GMT

I just got my copy of Sep 92 SunWorld yesterday. On pp.29-30, an
article describes how SunSoft apparently announced at Object World
that they will follow the OMG IDL as the way to define interfaces to
their implementations of distributed objects. 

The article goes on to say:

	At Object World, SunSoft announced a compiler front end,
	available on the Internet, royalty-free, to encourage people
	to "build to the (OMG) standard," ...

Anyone know more about this compiler front end (presumably for IDL to
the C language binding) and where you can get it?

-ted

--
Ted Kim                           Internet: tek@ficus.cs.ucla.edu
UCLA Computer Science Department  UUCP:     ...!{uunet|ucbvax}!cs.ucla.edu!tek
3680A Boelter Hall                Phone:    (310) 825-8524
Los Angeles, CA 90024             FAX:      (310) 825-2273
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 23 Aug 92 21:09:38 GMT
	<ARO.92Aug21170505@sibyl.aber.ac.uk> <91_n6rp.objsys@netcom.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 21 Aug 92 19:32:41 GMT, objsys@netcom.com (Bob Hathaway) said:

objsys> Piercarlo and I were discussing the hierarchical vs. graph
objsys> question, I was on the graph side (as I thought he was) and he
objsys> gave some meaningless example.  After providing some true
objsys> graphical examples and pointing out my graph orientation of
objsys> several years, he ignored my comments and then claimed I was
objsys> advocating the hierarchical approach!

		Version 0.1ALPHA of Bob Hathaway's opinions:

pcg> There is absolutely no reason to believe that structural reuse
pcg> opportunities need to happen in a hierarchical fashion like with
pcg> inheritance.

objsys> Sure there is.  We do it all the time; its called classification.

pcg> Yes, but all hierarchical taxonomies are inappropriate, in the sense
pcg> that they always cause bad classifications. 

		Version 0.2ALPHA of Bob Hathaway's opinions:

objsys> No, they don't.  As discussed under devices, they can be quite
objsys> appropriate.  And without an explicit inheritance relation there
objsys> can be excessive redundancy.

		ALPHA testing of these opinions:

pcg> Once wants the ability (my favourite peeve) to independently
pcg> reuse interfaces, specifications, and implementations, and a
pcg> general purpose algebra for all of thse things.

objsys> Some systems with inheritance may not provide this but I don't
objsys> see any inherent restrictions.

pcg> Well, except that you insist otherwise that type systems should be
pcg> hierarchical. Isn't that a fairly large inherent restriction?

		Version 0.5BETA:

objsys> No I don't and never have.  As pointed out above, the is-a
objsys> relation does not have a hierarchical restriction and indeed
objsys> further justifies the separation of type and class.  I defended
objsys> classification, not strict hierarchies.



Comp.object as an ALPHA/BETA test site for opinions. Wonderful for some.

Unfortunately I am currently busy and I can only afford to debug
released opinions, I have not got much time to track ALPHA or BETA ones.

And released opinions, like Ralph Johnson's, take a lot of time to test.
I am also working, slowly, on an extended benchmark of the whole suite
of Wegner/Cardelli opinions, as released in 1985; progress is slow also
because they were still ALPHA quality opinions, too bad they got
incorporated into too many people's opinions applications, even
nowadays.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Xref: sparky comp.object:3370 comp.lang.eiffel:1103 comp.lang.smalltalk:1753
From: kend@data.rain.com (Ken Dickey)
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.smalltalk
Subject: Re: Future Issues of Object Orientation
Date: 1 Sep 92 21:37:16 GMT
Distribution: usa
Organization: Microtek DSD, Hillsboro, OR

dvorak@ast.dsd.northrop.com (dvorak joseph l.) writes:

> I would like to start a discussion about what people believe
> will be the critical issues in object technology in the next
> 5 - 8 years. What solutions to these issues do you see and
> how will the solutions affect the object model?

I just have time for a few...

There are a large number of issues surrounding persistent computations
(ones which span a number of power-downs, migrate to newer/different
HW) and persistent distributed objects in general.  Doing persistence
without global tables will be more important.

My guess is that static typing and direct inheritance lose out over
typed values and delegation style inheritance as mutability and the
ability to "proxy" over a network become more important.  It is
horribly bad to export complex type signatures when you want to export
some object interface.  I expect interfaces to become more
encapsulated. 

Another area of interest is the ability to mutate distributed objects
over time.   For example, you have a running connection server with live
data used over a network and you want to "install" a new version
without bringing down the server or interrupting its sessions.  This
essentially requires a transformation algebra which deals with both
the live data and live connection issues.

Robust systems and recovery will continue to grow in importance.  When
a bridge falls down, people go after the (civil) engineer(s) which
designed it.  I expect that people will start building software
systems differently as we "software engineers" are held more
accountable for software system designs.


-Ken Dickey
Newsgroups: comp.object
From: wtchang@csie.nctu.edu.tw (Wen-Tsung)
Subject: Current development of O.O architecture / machine
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: Tin 1.1 PL5
Date: Thu, 3 Sep 1992 07:21:47 GMT

  Can anyone tell me the current development of object-oriented architecture / machine, or how can I get such information ?

  Thanks.

  Eric.                     e-mail : wtchang@csie.nctu.edu.tw

Newsgroups: comp.object
From: ywlee@sparc2.cs.uiuc.edu (Youngwhan Lee)
Subject: Versant, Objectivity or any other OODB language?
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 31 Aug 1992 04:37:14 GMT

Hi,
Do any of you out there know anything about Versant and/or Objectivity?

In particular, I need to know,

1) who are the manufacturers?, telephone numbers? addresses?
2) Pros and cons?
3) We are to investigate writing a DB application. Are they right
candidates for the programming tool? 
(I don't even knwo what they exactly are. :-P

Thanks in advance.

youngwhan.
-- 
ywlee@uiuc.edu, ywlee@cs.uiuc.edu           | University of Illinois
1408 W. University Ave., Urbana, IL. 61801  | Computer Science 
(217) 244-7551   			    |
Yes, I believe in science, but nothing else.| Innosys? What is it?
Newsgroups: comp.object
From: smccoy@dw3g.ess.harris.com (Scott McCoy)
Subject: Re: DFDs come naturally
Date: Thu, 3 Sep 1992 12:44:42 GMT
Reply-To: smccoy@dw3g.ess.harris.com (Scott McCoy)
Organization: Harris Corporation Information Systems Division

In article <1992Sep1.143121.29965@matrix.com>, srm@matrix.com (Steve
Morris) writes:
|>
|>I have some background in OO techniques. However, every time I
|>start
|>to analyze a system via diagrams, I naturally (i.e.
|>not-consciously)
|>start to draw a data-flow diagram.
|>
|>I don't necessarily say to myself... "Today, I'm going to use
|>structured analysis". It just comes out that way.
|>
|>Has anyone else experienced this?
|>
|>To those of you who use OOA; does your OOA method come naturally
|>or do you consciously apply it?
|>
|>
|>-- 
|>Steve Morris  ||  MATRIX Corp.  ||  919-231-8000 (8001 FAX) || 
|>srm@matrix.com
|>

I have the same problem: when I see bubbles and flows, I also think of 
DFD's.  I think that is a serious failing point (IMHO) of some of the 
CASE tools which market 'OO' support, but really just provide a 
re-packaged DFD tool.

Old habits are hard to break.

Try an OO methodology which does not use bubbles and flows
(Coad/Yourdon comes to mind -- works "naturally" for me).

--
Scott McCoy	Harris ISD	Opinions expressed are my own.
		Internet: 	smccoy@dw3g.ess.harris.com
		Voice   : 	(407) 242-5315
		FAX     : 	(407) 242-4249
Xref: sparky comp.object:3324 comp.lang.c++:12904 comp.lang.eiffel:1084 comp.lang.smalltalk:1697
From: dvorak@ast.dsd.northrop.com (dvorak joseph l.)
Newsgroups: comp.object,comp.lang.c++,comp.lang.eiffel,comp.lang.smalltalk
Subject: Future Issues for Object Technology
Date: 24 Aug 92 18:13:56 GMT
Organization: Northrop Corp - ESD, Rolling Meadows, IL


 I would like to start a discussion about what people believe
 will be the critical issues in object technology in the next
 5 - 8 years. What solutions to these issues do you see and
 how will the solutions affect the object model?

 If you do not wish to or cannot post your answer, you can
 mail it to me. I will post a summary of all mailed replies.
From: objsys@netcom.com (Bob Hathaway)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: 2 Sep 92 20:29:22 GMT
Organization: Object Systems


  [Thanks for the wrap-up Chris.  I'll try to answer a few pointed questions
   but this isn't an attempt to start over; we need to move on to the new.]

In article <KERS.92Sep2121520@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>Bob suggests that he's going to produce a book explaining his views more
>fully.
>
>I look forward to reading it. Have you a publisher?

No, I was just kidding.  I might write one eventually though.

>-- On modes of discourse ----------------------------------------------
>...
I agree.  My excuse: There are not enough hours in the day for me and when
plenty of them start getting consumed I start getting irritable (but thanks
for bearing with me).

>| You seem to have latched on to some trivial static efficiency tricks and
>| took them as the general case.
>  ... [Why me?] ...

C++ and other statically (strongly) typed object-oriented languages do
only switch on the first parameter; all other argument types must be
contra-variant with respect to subtyping.  C++ even forces argument
types (and currently return types) to be the same [for virtual functions].
This is close to what you said: "only the first argument type is used and
the rest are ignored".  This is also a trivial static efficiency trick.
This is what I was referring to above, the other case of a statically
typeless language (Smalltalk) also only switches on the first argument type
but includes keywords in the matching.  This is because Smalltalk is a
prototype language and doesn't provide types for argument matching (and
only keywords, it should be both); a weakness of Smalltalk and clearly not
of OO or of the O M ... notation.

>-- On finance ---------------------------------------------------------
>
>| But don't worry, my consulting fee is only $500 an hour and I'll just bill
>| you;-)
>
>The billing (if not the cooing) will be mutual, I'm sure :-)

That should work out equitably for both of us!-)

bob
objsys@netcom.com
Newsgroups: comp.object,comp.lang.clos
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: Thu, 03 Sep 92 00:23:42 GMT
Organization: Object Systems
Followup-To: comp.object

In article <j1kn6ll.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
>>...
>>        INTERSECT((x, LINE) (y, CIRCLE))
>
>In "OOP" the INTERSECT function could be made a "friend" of LINE and CIRCLE
>granting INTERSECT access to both classes without violating a strong form of
>encapsulation.  Perhaps "strict OO messaging" could be substituted for "OOP".
>But I'd keep in mind that such implementation access isn't always a good thing.

I may have jumped the gun.  Simple functions can do the trick; access via
a "friend" mechanism is only required for accessing an implementation (which
is an efficiency trick and disastrous for multiple implementations).  But I
still don't understand why people think functions in CLOS are special;
except for their left-to-right ordering and lack of default protection for
their arguments they're still just ordinary polymorphic functions invoked at
run-time.  Maybe the run-time function invocation not being so commonly
available explains why this is considered special (and is to CLOS' credit).
But the lack of default protection means no multiple-implementations per
type; a severe restriction that I doubt even CLOS' intercessory protocols
can overcome.  Am I wrong here?  Can CLOS provide for the separation of
types and classes (or any kind of multiple implementations per type)?

bob
objsys@netcom.com

P.S.  Going typeless is not an acceptable answer.
Newsgroups: comp.object,comp.lang.clos
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Implementation Question
Organization: School of Mathematics and Statistics, University of Sydney
Date: Wed, 2 Sep 1992 11:58:45 GMT

I was wondering about a small implementation problem I am having.
Imagine I have two classes A and B defined as follows,

	class A
		instance variables a, b, c;
	end class;

	class B
		subclass of class A;
		instance variables e, f;
	end class;

(by "instance variable" i mean that an instance of class A will
have three "fields"/"slots" (pick your terminology!) named a, b and
c).

Now my problem is as follows. How do OO implentations handle the 
space allocation for an instance of class B? Does an instance of B
have to have space allocated for all the instance variables in B as 
well as all the instance variables in all the classes of which B is 
a sub-class (in this case class A). I ask this for three reasons :-

a) I have many examples where B is a subclass of A but one rarely
utilises this feature. All the time is spent computing with instances
of B as instances of the sub-class B and not as instances of the 
super-class A. So I do not want to allocate space for any instance 
variables (in this case those in class A) which I am rarely if ever 
going to use.

b) I have example code where the representation of B is not the
same as A. That is mathematically B is a sub-type of A but for
various reasons the implementation of B does not have any of the 
slots of A.

I can think of one solution using associative arrays, but this must
be a standard problem with a set of standard solutions.

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
Newsgroups: comp.object
From: vv@mbunix.mitre.org (Ventrone)
Subject: Re: Advanced Degrees in OOP
Keywords: OOP education
Organization: The MITRE Corporation, Bedford, MA
Distribution: usa
Date: Tue, 1 Sep 1992 16:48:41 GMT

In article <47021@shamash.cdc.com> paul@svl.cdc.com (Paul Kohlmiller) writes:
>I would like to get an advanced degree in CS with an emphasis in
>OOP. Since I am not able to quit work to do so, I need a program
(stuff delted...)
>What I would like to see is a program similar to the University of
>Phoenix program that leads to an MBA.
>I hope that this starts a thread of ideas that we can use to come up
>with some kind of program. I have no idea how we could get this program

Did I read that correctly--is this proposing an MBA in OOP or a program 
in OOP that leads to a degree the way that the program at Phoenix in 
business leads to an MBA??  If the former, that seems like a strange idea--
why would anyone take an MBA in OOP seriously?  (or, for that matter, take 
an MBA in ANYTHING seriously :-)
-- 
   Vince Ventrone
   The MITRE Corporation       "...In my opinion, there's nothing in this
   Bedford, MA 01730           world beats a '52 Vincent
   vav@mitre.org               and a redheaded girl."  -- Richard Thompson
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Thu, 3 Sep 1992 09:13:40 GMT
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.object

In article ... objsys@netcom.com (Bob Hathaway) writes:


   >| You seem to have latched on to some trivial static efficiency tricks and
   >| took them as the general case.
   >  ... [Why me?] ...

   C++ and other statically (strongly) typed object-oriented languages do
   only switch on the first parameter; all other argument types must be
   contra-variant with respect to subtyping.  C++ even forces argument
   types (and currently return types) to be the same [for virtual functions].
   This is close to what you said: "only the first argument type is used and
   the rest are ignored".  This is also a trivial static efficiency trick.
   This is what I was referring to above, the other case of a statically
   typeless language (Smalltalk) also only switches on the first argument type
   but includes keywords in the matching.  This is because Smalltalk is a
   prototype language and doesn't provide types for argument matching (and
   only keywords, it should be both); a weakness of Smalltalk and clearly not
   of OO or of the O M ... notation.

Hmm. The keywords in SmallTalk are just part of the message name, so I don't
think they matter from the point of view of types; but that may depend on how
you carve up your object orientation.

It's never been clear to me whether you've been arguing from the *descriptive*
stance (``this is how certain languages *are*''), the *prescriptive* stance
(``this is is how languages *should be*''), or the *analytic* stance (subcase
of descriptive; ``this is how languages *could be seen*'').

Thus, C++ and other statically typed OO languages *do* only dispatch on one
(the ``first'') argument [anyone have a counter-example?], but they *need not*
-- that is, static typing does not conflict with many-arg dispatch. And, in
fact, I don't think it's a ``trivial static efficiency trick'' -- given the (a)
alternative, such as CLOS-style multi-methods, which are quite hard to
implement efficiently in the general case, it's a rather elegant solution.

It's just that it's not the solution that some of us want ...
--

Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
From: hoelzle@Xenon.Stanford.EDU (Urs Hoelzle)
Subject: Re: Future Issues of Object Orientation
Organization: CS Department, Stanford University, California, USA
Distribution: usa
Date:  2 Sep 92 00:03:59 GMT

sm86+@andrew.cmu.edu (Stefan Monnier) writes:

>Self (which is since recently available at self.stanford.edu in version 2.0)
>claims to approach the C speed although it is FULLY dynamic
>(even dynamic inheritance) by special 'run-time' compilation (which
>writes different versions for special cases) !

This is a little bit of an overstatement: not all Self programs
approach C speed (yet :-).  However, on the (C-like) Stanford integer
benchmarks Self does very well.  

Speed discussions somewhat remind me of the 70s "C (or Pascal or..)
versus Assembler".  At that time, people had to decide between higher
productivity (i.e. a high-level language) or a factor of around 2-3
performance gain (assembly).  Most people chose the "slow" high-level
languages for normal applications, and I don't think anyone regrets
it.  Furthermore, as compiler technology advanced, the performance gap
narrowed considerably.  

To me, today's "should I use {Eiffel, Smalltalk, Self} or C" sounds
like a deja vu.  If OO really helps productivity, it's worth a certain
performance hit (the factor depends on the application, of course).
If you can design and implement your new fancy application in half the
time, you're better off than an application that is twice as fast but
comes to market much later.  

-Urs

----------------------------------------------------------------------------
Urs Hoelzle                                              urs@cs.stanford.EDU
Computer Systems Laboratory, CIS 57, Stanford University, Stanford, CA 94305
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: 28 Aug 92 07:32:47 GMT
	<BEVAN.92Aug26090351@beluga.cs.man.ac.uk> <31cnnr+.objsys@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: objsys@netcom.com's message of 27 Aug 92 19:50:22 GMT

In article <31cnnr+.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
   [ use CLOS terminology in preference to Bob + Coplien ]

   Then we'd be left with the more verbose but precise: "multiply-polymorphic
   methods" terminology.  People might still get confused over whether
   "methods" referred to CLOS, classical OO or some other kind of method.

So?  Do you claim that if we all adopt your terminology there will be
no confusion?


   CLOS stores methods specialized to a class with that class anyway. 

Shouldn't that be "CLOS stores methods specialized to _classes_ with
_those_ classes anyway" as the whole point is that it allows you to
specialise on more than one argument.  Anyway, what does it matter how
it is _implemented_, it is the semantics that are important.

bevan
Newsgroups: comp.object