* Re: Ada OOP question [not found] ` <wvtY5.11680$Ei1.812152@bgtnsc05-news.ops.worldnet.att.net> @ 2000-12-11 21:52 ` Randy Brukardt 0 siblings, 0 replies; 5+ messages in thread From: Randy Brukardt @ 2000-12-11 21:52 UTC (permalink / raw) James S. Rogers wrote in message ... >The question clearly comes from a person who has learned C++ or Java. >Those languages allow classes to be defined with mixtures of public and >private data. > >The same effect can be achieved in Ada, although the syntax is not as clean >as in C++ or Java. > >A tagged type in Ada is defined either in the public or private area of a >package specification. It is not defined partially in the public area and >partially in the private area. At first glance this seems to forbid creating a >tagged type with both public and private data members. There is a solution. > >In Ada you need to extend the inheritance hierarchy a little deeper to >achieve your goals. Follow these steps: > >1) Declare a tagged type in the public part of a package specification. >2) Extend that tagged type with a private extension in the private part of a > child package specification. >3) Inherit all future tagged types in that class from the child package with the > private definition. It's not necessary to create a separate package for the extension (IF you're careful with the placement of primitive operations). This is an important difference between C++ and Ada (since the encapsulation and inheritance mechanisms are separate in Ada). If your only purpose is to have both kinds of components, make the original type abstract so no one can accidentally create an object of it (without the private components): (We use this technique in Claw to hide locks associated with some objects...) package Employee_Package is type Public_Employee is abstract tagged record -- No objects of this are allowed. Name : String(1..30); Age : Positive; Employee_Id : String(1..8); Title : String(1..20); end record; type Employee is new Public_Employee with private; -- Follow with public subprograms appropriate to -- the above tagged type definition private type Employee is new Public_Employee with record Salary : Float; end record; end Employee_Package; >Every instance of the Employee tagged type, or any instance in its >class hierarchy, will have both public and private data members. Randy Brukardt R.R. Software, Inc. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <kduY5.4872$M5.273278@news1.frmt1.sfba.home.com>]
[parent not found: <3A32A182.54E3D857@acm.org>]
[parent not found: <91382k$nq1$1@nnrp1.deja.com>]
* Re: Ada OOP question [not found] ` <91382k$nq1$1@nnrp1.deja.com> @ 2000-12-12 5:14 ` Jeff Carter 2000-12-14 19:00 ` mark_lundquist 0 siblings, 1 reply; 5+ messages in thread From: Jeff Carter @ 2000-12-12 5:14 UTC (permalink / raw) mark_lundquist@my-deja.com wrote: > Baloney! How is mixing public and private any more EVIL than having > all components public, which Ada makes no more difficult than any other > language? Arguably, if one feels that some component of an abstraction > must be public, it's still better to have the rest private than to make > all public, wouldn't you say? I think one could make a case that > public components in general are about the same level of evilness as > goto, i.e. easy to abuse, but also easy enough not to abuse, and the > abuse is of a kind that is more a consequence of bad design than a > cause. 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. This doesn't bother C++ people, who expect the client to read the implementation to learn how to use a type. 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. -- Jeff Carter "I blow my nose on you." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ada OOP question 2000-12-12 5:14 ` Jeff Carter @ 2000-12-14 19:00 ` mark_lundquist 2000-12-14 23:05 ` Jeff Carter 0 siblings, 1 reply; 5+ messages in thread From: mark_lundquist @ 2000-12-14 19:00 UTC (permalink / raw) In article <3A35B45D.5F05F171@acm.org>, Jeff Carter <jrcarter@acm.org> 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ada OOP question 2000-12-14 19:00 ` mark_lundquist @ 2000-12-14 23:05 ` Jeff Carter 0 siblings, 0 replies; 5+ messages in thread From: Jeff Carter @ 2000-12-14 23:05 UTC (permalink / raw) mark_lundquist@my-deja.com wrote: > > 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... I disagree. If I write the package with no public components, I can easily detect invalid sequences of operations. I can often prevent invalid sequences of operations. This is less easy when one of the operations is direct assignment to components of the 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. Too frequently there are no comments anywhere. The code is "self documenting". > 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... "Performance" is often used as an excuse for bad design. "We have this variable in the package spec for performance reasons." "Really? Where are the performance requirements documented? Where are the results of timing tests without the global variable documented?" "Well, there aren't any. I just know it will be too slow otherwise." Such claims are rarely true. -- Jeff Carter "I waggle my private parts at your aunties." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Ada OOP question [not found] <20001209101904.07653.00004016@ng-fy1.aol.com> [not found] ` <wvtY5.11680$Ei1.812152@bgtnsc05-news.ops.worldnet.att.net> [not found] ` <kduY5.4872$M5.273278@news1.frmt1.sfba.home.com> @ 2000-12-12 21:57 ` Stephen Leake 2 siblings, 0 replies; 5+ messages in thread From: Stephen Leake @ 2000-12-12 21:57 UTC (permalink / raw) hdhil@aol.com (HDhil) writes: > Simple question re Ada OOP: Does Ada 95 allow > the specification of public components? One solution is: package My_Package is type My_Object_Private is private; type My_Object is record public_1 : foo; public_2 : bar; private_1 : My_Object_Private; end type; private type My_Object_Private is record private_stuff : foo_bar; end record; end My_Package; Clients of this package can copy private_1, but can't examine inside it. If copying is bad, use a limited private type. -- -- Stephe ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-12-14 23:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20001209101904.07653.00004016@ng-fy1.aol.com> [not found] ` <wvtY5.11680$Ei1.812152@bgtnsc05-news.ops.worldnet.att.net> 2000-12-11 21:52 ` Ada OOP question Randy Brukardt [not found] ` <kduY5.4872$M5.273278@news1.frmt1.sfba.home.com> [not found] ` <3A32A182.54E3D857@acm.org> [not found] ` <91382k$nq1$1@nnrp1.deja.com> 2000-12-12 5:14 ` Jeff Carter 2000-12-14 19:00 ` mark_lundquist 2000-12-14 23:05 ` Jeff Carter 2000-12-12 21:57 ` Stephen Leake
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox