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:1122315253.757948.150350@z14g2000cwz.googlegroups.com...
> Erm, they are tagged and in some cases I have needed "aliased" to get
> hold of the actual address of the item, i.e. when connecting an event
> handler to a frame, you have to give it the address of the event
> handler, the lib currently uses this address internally as well.

Tagged parameters are automatically aliased, so you don't need to declare
them explicitly. So it's only necessarily if you're declaring objects
(either stand-alone or components). I'd suggest that that be kept to a
minimum; it's best to let the user code manage the actual objects (which
often will be extensions of some sort). So it should be rare to need to
specify aliased.

In your above description, I'm assuming that the event handler and the frame
are objects passed in to the various routines. In that case, just taking
'Unchecked_Access works fine. If the event handler is some sort of local
object, then of course you'd need aliased. But in this case, this is an Ada
object, but it isn't an "object" in the software engineering sense from
outside of the library. It's not unusual to have to do all sorts of grunge
inside the library, but that's irrelevant. It's not important that *you*
have to declare something aliased; it only matters that you don't force your
users to do so. As long as objects are tagged, that should be the case.

> The lib is already a thick binding:
>
> 1) A mirror of the class hierarchy from C++ into Ada tagged types.
> 2) The primitive operations call imported C functions which in turn
> call the necessary C++ methods.
> 3) Conversions between Ada and C types is done inside the lib and you
> never deal with a C.int/long or chars_ptr.

Sounds good. Good luck with the design.

                                Randy.