Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!cam-news-feed3.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!howland.erols.net!news.mathworks.com!uunet!in3.uu.net!uucp4.uu.net!alexandria.organon.com!alexandria!jsa
From: jsa@alexandria (Jon S Anthony)
Subject: Re: OO, C++, and something much better!
In-Reply-To: eachus@spectre.mitre.org's message of 04 Feb 1997 02:39:04 GMT
Message-ID: <JSA.97Feb4172010@alexandria>
Sender: news@organon.com (news)
Organization: Organon Motives, Inc.
References: <JSA.97Jan16141937@alexandria> <E44u82.6uB@syd.csa.com.au>
	<mheaney-ya023280001601972303180001@news.ni.net>
	<32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com>
	<32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU>
	<32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com>
	<32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu>
	<32E47B4B.56D9@concentric.net> <32E4E6E1.437E@dstsystems.com>
	<32EE858E.FAD@concentric.net> <5cobea$cm8@news1.ucsd.edu>
	<32F07705.289C@concentric.net> <JSA.97Jan30205754@alexandria>
	<32F3A1E4.2F6@concentric.net> <EACHUS.97Feb3213904@spectre.mitre.org>
Date: Tue, 4 Feb 1997 22:20:10 GMT
Lines: 50
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:245559 comp.lang.smalltalk:50933 comp.lang.eiffel:18190 comp.lang.ada:57166 comp.object:60823

In article <EACHUS.97Feb3213904@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

> In article <32F3A1E4.2F6@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
>   > Unless "D1 := D2" is a legal assignment, your example falls short of 
>   > what I was asking for (and perhaps even then, but I'm not fluent enough
>   > in Ada95 to be sure).
> 
>    Hmmm.  First, you need to change the line:
> 
>      type Object is abstract tagged limited null record;
> 
>   to:
> 
>      type Object is abstract tagged null record;
> 
>    That will allow D1 := D2; to "work."

Not sufficient.  You would then also need to change the definition of
Dictionary as it could not then have an access discriminant.  OTOH, to
me there is no obvious reason _why_ you should even allow such an
assignment.  It's confusing, it's error prone and it serves no useful
purpose.  Actually, I don't understand what's so great about exposing
the implementation anyway.  And that's exactly what you are doing by
having the Binary_Tree and Hash_Table choices being made by the
_client_ who simply wants to use a damn dictionary.

"Oh, but see, the client (or more precisely programmer of client)
might know that the Binary_Tree impl is "better" than the Hash_Table
impl or vice versa."

Maybe.  But that is based on some other more relevant information -
like scalability, speed, footprint, etc.  These much more relevant
constraints, and how they can be achieved (or not), should be spelled
out by the component offering the service.  The most appropriate
implementation for the chosen set of constraints can then be selected
by the service without the client having to drop to this low level
inappropriate detail.  Furthermore, it is not likely that the client
writer will know anywhere near as much about the various best ways of
achieving the constraints for the service.  After all - that's not his
job (or at least it sure shouldn't be).

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

