Re: Self pointer in limited record

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 06 Sep 2007 12:26:45 +0200, Georg Bauhaus wrote:

> On Thu, 2007-09-06 at 09:37 +0200, Dmitry A. Kazakov wrote:
>> On Wed, 05 Sep 2007 23:38:34 +0200, Georg Bauhaus wrote:
>> 
>>> They can avoid surprises and nasty issues because they enforce body
>>> visibility of data objects. Example:
>>> 
>>> <start of declarative part>
>>> 
>>>         package S is
>>>                 type T is limited private;
>>>                 procedure op(x: in out T);
>>>         private
>>>                 type T is limited record
>>>                         null;
>>>                 end record;
>>>         end S;
>> 
>> This is IMO bad design, it should be:
>> 
>> package S is   -- Stateless
>>    type T is limited private;
>>    ...
>> end S;
> 
> IIUC, this will still allow referencing S.T elsewhere.
> And even when S has only subprograms, they are visible to
> other parts of the program.
> But S was intended to be used by some procedure,
> and only by the procedure.

If you are paranoid about treacherous intentions of your colleges, then
make S a private child:

private package Data.S is
   type T(<>) is limited private;
   ...
end Data.S;

>> package Data is -- Stateful
>>    ... -- Operations having an instance of T as a hidden parameter
>> end Data;
>> 
>> with S;
>> package body Data is
>>    Singleton : S.T;
>>    ...
>> end Data;
>> 
>> There is no need to "with" S for anybody else,
> 
> Do you think that "No need to with S" will convince programmers
> to not touch it?

Yes, I do hope they would not do it if I'd ask them, as well as many other
things one could do being inspired by the things declared in System,
Ada.Unchecked_xxx etc.

> When I need to make sure that S is not going
> to be used elsewhere, it needs to be hidden. What are the options?

Safe and consistent design. Consider what is T in your model? Why there has
to be only one instance of? Which meaning has this in terms of the
operations on T? Who knows, you might come to a conclusion that this
constraint is not really necessary or maybe that it is enforced
automatically when T is properly used.

In real-life designs there are usually far more access levels than just
public/private/body with fuzzy boundaries between them. You have to rely on
your design and good will of people working with you.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de