From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b3e32a261c552ef1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-14 11:10:18 PST Path: supernews.google.com!sn-xit-02!supernews.com!isdnet!newsfeed.direct.ca!look.ca!netnews.com!wn4feed!worldnet.att.net!128.230.129.106!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: mark_lundquist@my-deja.com Newsgroups: comp.lang.ada Subject: Re: Ada OOP question Date: Thu, 14 Dec 2000 19:00:06 GMT Organization: Deja.com Message-ID: <91b5bi$7qq$1@nnrp1.deja.com> References: <20001209101904.07653.00004016@ng-fy1.aol.com> <3A32A182.54E3D857@acm.org> <91382k$nq1$1@nnrp1.deja.com> <3A35B45D.5F05F171@acm.org> NNTP-Posting-Host: 130.213.200.194 X-Article-Creation-Date: Thu Dec 14 19:00:06 2000 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Http-Proxy: 1.1 x56.deja.com:80 (Squid/1.1.22) for client 130.213.200.194 X-MyDeja-Info: XMYDJUIDmark_lundquist Xref: supernews.google.com comp.lang.ada:3142 Date: 2000-12-14T19:00:06+00:00 List-Id: In article <3A35B45D.5F05F171@acm.org>, Jeff Carter wrote: > > You have presented no evidence to support your claim of baloney. Salami, > perhaps. :-) > > Seriously, I was employing hyperbole in describing it as EVIL. However, > I think that this practice should be discouraged. The problem is that > such a type creates an interface that is difficult to understand. What > is the difference between > > Op (Object, Param1, Param2); > > and > > Object.Public_Component := Some_Value; > Op (Object, Param1, Param2); > > ? They could be the same; Op could perform differently in the 2nd case, > but this be considered valid; or Op could be invalid as a result of the > assignment. Sure... but this observation is just as valid if you replace the assignment to the public component with any operation. Since encapsulation isn't relevant to your observation, the observation isn't a sound argument for encapsulation in general nor against mixing public and private components in particular. (Don't get me wrong, I'm all for encapsulation, this just isn't the argument for it! :-) Your argument below, viz. coupling to the implementation, is much more to the point... > > This doesn't bother C++ people, who expect the client to read the > implementation to learn how to use a type. > True enough, it's the "header file" heritage. In C you often find a function's documentation comments in the .c file, while the .h file (ostensibly the "interface") is just "extern blah blah(blah, blah);" on everything, with no comments. > Frequently such components > are used both to shorten parameter lists and store state between calls. > > In general, visible components in an abstraction are a bad idea, > including when they are all visible: you cannot change the > implementation without changing the interface. There you go, that has always seemed to me to be the "real" argument. I wonder if the reason people sometimes use public components instead of accessors/mutators (or getters/setters or whatever you want to call them) because they are trying to "optimize performance". Certainly in C++ it's well known that member functions defined in the class definition are inlined, but maybe people don't know that you can inline subprograms in Ada (Rational's compiler does auto-inlining when optimization is turned on, and its algorithm is quite difficult for a human programmer to beat in terms of final executable speed and size). Don't know about inlining in Java... Mark Lundquist Rational Software Sent via Deja.com http://www.deja.com/