Re: Private primitive operations available to entire package hierarchy. Can it be done?

["Randy Brukardt" <randy@rrsoftware.com>]

"Lucretia" <lucretia9@lycos.co.uk> wrote in message
news:1122485760.918191.274380@f14g2000cwb.googlegroups.com...
...
> In my minimal sample I derive a new Frame_Type and within that I have
> declared a Button_Type instance, i.e.
>
> type Minimal_Frame_Type is new Frame_Type with
>   record
>     ...
>     Button : aliased Button_Type;
>     ...
>   end record;
>
> Now, in the code I do this:
>
> Add(Some_Sizer, Self.Button'Unchecked_Access...);

Is this in the user code, or in the implementation of the interface? If it's
in the implementation of the interface, do whatever you have to do. If it's
in the user code, though, I'd claim that the Add routine is incorrectly
specified -- it should simply pass the Button_Type object and the code
*internal* to the binding should be creating the access types.

> If I remove the aliased, it wont compile because Button is not aliased
> (it is rooted at Object_Type like all other wxAda types).

It will if Button is a parameter, rather than a component.

> If I keep aliased but use 'Access it doesn't compile because it is a
> local object - I have also tried allocating the Minimal_Frame_Type
> using new rather than having a "global" and it still requires the
> aliased.

Right. I've never found a case where I could actually use 'Access on an
object.

> Because of all of this, I am seriously considering using pointers to
> these instances rather than just instantiating them, i.e.:
>
> type Minimal_Frame_Type is new Frame_Type with
>   record
>     ...
>     Button : Button_Access;
>     ...
>   end record;
>
> type Minimal_Frame_Access is access all Minimal_Frame_Type;
>
> and having all primitives take an access parameter as the controlling
> parameter.

That's awful. If you do that, you're requiring your user to do memory
management for you, rather than the other way around. They'll be forced into
subpar syntax (explicit uses of aliased and 'Access), have runtime
accessibility errors, and other nastyness. And they would have no way to use
the containers library do the storage management for them.

My rule of thumb (not shared by all, mind you) is that explicit access types
in the user accessible specifications should be kept to an absolute minimum.
In Claw, we use them only to avoid copying of objects for query functions.
Everything else is passed as an object.

Internal to the library, of course, virtually everything is an access type.
But that sort of grunge is completely hidden from the user. We use the
predefined Finalize routine to insure that dangling pointers don't get left
around - when an object is finalized, it is removed from all internal
objects to which it is linked.

So, at the user level, I'd suggest something like:

    procedure Add (Sizer : Sizer_Type; Button : Button_Type'Class);

And the implementation of Add:

    procedure Add (Sizer : Sizer_Type; Button : Button_Type'Class) is
         My_Button : Any_Button_Access_Type := Button'Unchecked_Access;
         My_Sizer : Any_Sizer_Access_Type := Sizer'Unchecked_Access;
    begin
         -- Call the low level (C) routines:
         wx_Add (My_Sizer, My_Button);
         -- etc.
    end Add;

You might need to do some type conversions on the access types, but that's
OK as it doesn't usually generate any code.

                                Randy.