Re: Building limited types through nested creator functions

[Simon Belmont <sbelmont700@gmail.com>]

On Feb 6, 7:53 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Feb 6, 4:27 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
>
> > On Feb 6, 7:03 pm, Adam Beneschan <a...@irvine.com> wrote:
>
> > > (2) If you want users of the package to create an Inner, and then
> > > create an Outer that *refers* to that same Inner (without making a
> > > copy), then you shouldn't object to using access types (in the private
> > > part).
>
> > It is basically this, and I really have no objection in using the
> > access type.  But since Ada can do it for a public type, I was just
> > interested if there was some sort of official way for a private type
> > (which would avoid the necessary evils of lifetime control,
> > accessibility, etc.)
>
> For a public type, the program has the information that an Outer
> contains an Inner (assuming you don't use access types).  Thus it can
> create the Outer and its Inner at the same time, using a single
> aggregate.  You can't create an Inner first and then create an Outer
> later, even if it's a public type.
>
> Since this information is private, the body of your package is the
> only one that knows that an Outer contains an Inner; therefore, it's
> the body of your package that has to create an Outer and an Inner at
> the same time.  Based on that, I don't think your objection to
> Shark8's solution makes sense.
>
> I'm assuming here that you really want an Outer to *contain* an Inner,
> rather than an Outer containing a *reference* to an Inner.  And I mean
> this in terms of an abstract description of your problem, not in terms
> of using an access type as your mechanism for implementing all this.
> But since you're now saying that an Outer actually *refers* to an
> Inner, in your problem description, I guess the whole discussion may
> be moot.  You really are going to have to decide what you want.  Is an
> Inner a separate kind of object that you want package users to be able
> to have independently of an Outer?  Does it make sense for the program
> to declare a standalone object of type Inner and use it?  Or does an
> Inner make sense only as part of the larger Outer object?
>
>                              -- Adam

From a purely abstract view, then yes, one record 'has a' other, such
as a 'picture' or 'sound' or 'employee' type might contain a limited
file type within that it uses to read and write its data from disk.
They would have the same lifetime, and have a one-to-one
correspondance.  The issue is that I don't want to couple the outer
type to the concrete type of the inner; suppose Inner is really
Inner'Class, and Outer should remain abstract enough to work given any
concrete type upon initializtion (perhaps File could be any number of
concrete types that perform various encryption/compression, etc).  A
'normal' object cannot be passed in due to the aforementioned problem,
the arguments cannot be forwarded over because the Make_Inner would be
specific to one concrete type, and access values seem unnecessary for
this situation.  I suppose the 'right' thing to do would be to create
factory-type objects so that all Make_Outer has to do is call some
hypothetical Create function of the argument, but I didn't want to
waste my time if there was a method involving less typing.

Thank you again

-sb