Re: Ada202X: Easy to use "UML private"-like components

[Martin <martin@thedowies.com>]

On Friday, June 21, 2013 11:14:12 AM UTC+1, G.B. wrote:
> On 21.06.13 11:33, Martin wrote: > On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote: >> On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de > > But no easy means of keeping member data private from children. But no pointers needed; I hope the following example is a reasonably accurate paraphrase of a hint given by Tucker Taft some years ago, memory is vague. Not sure if UML has a concept for capturing this, but confident that Grady Booch knows Ada's visibility rules well. (Or should one find a sentence that has "possibilities" instead of "rules"?) package Opaque is type Exposed is tagged private; private package Invisible is type T is tagged private; private type Scalr is range 1 .. 2; type T is tagged record Comp_1 : Scalr; end record; end Invisible; type Exposed is new Invisible.T with null record; end Opaque; private package Opaque.Child is A : Invisible.T; Y : Invisible.Scalr := A.Comp_1; end Opaque.Child; Compiling: opaque-child.ads (source file time stamp: 2013-06-21 10:06:44) 4. Y : Invisible.Scalr := A.Comp_1; 1 2 >>> "Scalr" is not a visible entity of "Invisible" >>> no selector "Comp_1" for private type "T" defined at opaque.ads:8 5 lines: 2 errors Thus, even a private child cannot see anything behind doubled fences. I imagine that explaining this needs some spin doctoring.



Yeah, ok...hadn't thought of that way...

But really, it's still a bit embaressing and it's almost as bad as the access type solution...almost...

-- Martin