Package's private parts and protected types
in [ADA]
|
From: stefan-lucks on 9 Feb 2010 04:04 On Mon, 8 Feb 2010, Robert A Duff wrote: > "(see below)" <yaldnif.w(a)blueyonder.co.uk> writes: > > > Strangely, LIS, his ancestor of Ada, did not do this but had distinct, > > separately compiled, interface, representation, and algorithm parts for the > > LIS equivalent of packages. I am still waiting for an Ada 20XY amandmend, which allows something like package Blah; is ... private is separate; -- you might find it in blah.separate.ads -- end Blah; -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------
From: Hibou57 (Yannick Duchêne) on 9 Feb 2010 05:58 On 8 fév, 15:56, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > "Hibou57 (Yannick Duchêne)" <yannick_duch...(a)yahoo.fr> writes: > Private parts are a kludge in the first place, and the way > they work with public protected types is even worse, as > you pointed out. > > However, I think you can get the hiding you want by using > a protected or synchronized interface. > protected, task and synchronized interface seems nice at first sight. All three because they states what things are, while hiding implementation details. The third one especially, because the Synchronized tray in clean- abstract (as the Ada 95 rationale says on purpose, there is mostly no difference, from a client point of view, between a protected type and a task type). But these interfaces type are too much restrictive. As an example, it does not allow to define a type which could be automatically allocated in a local scope. It impose a design where the client must rely on access to class-wide. This may be nice... but only it was decided to be so. If something else was to be done, we face a no choice-path. A direct consequence is also that it requires to use and manage dynamic allocation in a none-clean way, as the client must make direct use of an access type. If multiple types are to be defined with same consequences for each, things become not clean at all. I feel (at least from my point of view), the most practicable manner is still to define a private type with primitives, and wrap things inside that private type in the private part (so there may be no better design than the initially introduced one).
From: Hibou57 (Yannick Duchêne) on 9 Feb 2010 07:43 On 8 fév, 11:20, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > package P is > protected type T is > ... > private > ... -- Why is it here? Is it C++ or Ada? > end T; > private > ... -- It belongs here! Or better to the package body > end P; > About this klugde (as someone called it), here are some words which attempt to explain the reason of this syntax : Quoted from http://www.adaic.com/standards/95rat/RAThtml/rat95-p2-9.html (Rationale 95) > Alternative structures were also considered and rejected. One was > that the private part of a protected unit be visible to the > enclosing package. However, this was considered confusing, and felt > to be inconsistent with the visibility of the private part of a > subpackage. We also considered splitting the protected type (and > task) specification into two separate parts, with the private > operations and data components declared in a second part included > inside the private part of the enclosing package. However, this > seemed like an unnecessary extra syntactic complexity, so we finally > adopted the simpler suggestion from two Revision Requests (RR-0487, > RR-0628) of using private within the specification to demarcate the > private operations.
From: Robert A Duff on 9 Feb 2010 09:47 "Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)yahoo.fr> writes: > But these interfaces type are too much restrictive. As an example, it > does not allow to define a type which could be automatically allocated > in a local scope. I agree that it's good to avoid heap management when possible. But why can't you declare local variables of type My_Interface'Class, initialized with build-in-place function calls? - Bob
From: Robert A Duff on 9 Feb 2010 09:56
AdaMagica <christoph.grein(a)eurocopter.com> writes: > OK, but then you have a similar problem to Ada83's syntactically > unneeded bodies which Ada95 solved with a pragma. I think that problem is an illusion. There was a problem, but it was a problem with implementations, not with the language. How do we know if a given package spec has a body? Simple: look on the disk and see if there's a source file containing that body. In GNAT, that would mean looking for foo.adb. > How would you specify that there is a syntactically unneeded private > part (i.e. when there is no private type in the spec)? Same way. And as I said, my preference would be to eliminate private parts altogether. > I guess your ideas about specs, bodies, child packages and visibility > are very different from Ada as she is. You'd like a different girl, > wouldn't you;-) Girl? Heh. Ada is my favorite programming language (of the ones that exist in the real world). The changes I've suggested are minor improvements. So no, not "very different". And of course it's all fantasy -- I'm not seriously suggesting Ada should be changed in incompatible ways! - Bob |