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:1120752411.808598.292980@g49g2000cwa.googlegroups.com...
> Hi,
>
> In my work with wxAda, I've found a need for some primitives to be
> private to the outside of the "wx." package hierarchy, yet packages
> within "wx." need to acces them.
>
> e.g.
>
> The package "wx.Window" contains a function which creates an Ada type
> rooted at Window_Type for a specific C++ instance type and class name
> (i.e. "wxWindow", "wxTopLevelWindow", etc.). This is also required in
> other packages, yet I don't want an application using wxAda to be able
> to see/use it at all.

Put those operations in the private part of the root package of the
hierarchy. All of the child units will be able to see them and override them
if necessary, but programs outside the hierarchy cannot use them. Claw uses
this extensively. Warning: doing this is a sure-fire way to turn up
visibility bugs in Ada compilers.

> I have also added a factory to allow creation of Ada types from a C++
> class name, at the moment, I register each type within the statement
> part of a package body. Is there an easier way register these
> factories? Currently to register a factory the package needs to be
> "with'd".

Generally, I put the registration code in the elaboration part of the
package declaring the type. That means that each package declaring a type
has to "with" the registration package. That's better than the registration
package "with"ing all of the types. (I'm not certain that this structure
actually works with Ada 95, it certainly does with Ada 200Y using the
Generic_Dispatching_Constructor package).

> P.S: Has Ada0X been put back another year?

It looks to be about 6 months late. (Says the editor, who ought to know.)
But we've also taken a more realistic look at the approval schedule for the
standard, and that is likely to stretch well into 2006 and possibly even
2007.

WG9 has decided to continue to call the language "Ada 2005" in the interim.
I personally have reverted to "Ada 200Y", because the year really isn't
known, and I don't see any reason to use a misleading year in the interim.
That is, "Ada 9X" was a better name than "Ada 92" would have been during
development of that standard [yes, Ada 95 was supposed to be approved in
1992 on the original schedule.]. (It's best to use a different name before
and after approval of the standard anyway, so that old outdated material is
not found in web searches and the like.)

                               Randy Brukardt.