Consider two limited record types, inner and outer, with the former
nested inside the latter. If the records are public, then code can
initialize the outer by specifying an aggregate for the inner, as in:
type Inner is limited
record
e : Integer;
end record;
type Outer is limited
record
i : Inner;
end record;
o : Outer := Outer'(i => Inner'(e => 42));
However, if types are made private, suitable functions must be
provided to make the appropriate objects. If just Inner is private,
then this can be done (assuming simple creator functions that just
create the objects with the given values):
o : Outer := Outer'(i => Make_Inner(arg => 42));
but if both are private, then the following:
o : Outer := Make_Outer (arg => Make_Inner(arg => 42));
ends up being illegal, because in the code:
function Make_Outer (arg : Inner) return Outer is
begin
return Outer'(i => arg);
end Make_Outer
would end up trying to copy a limited type. For the cases in which an
existing object is passed in, this would be the appropriate action,
but for cases where the object is built-in-place into the argument,
clearly the intended behavior is to build it in place to the resultant
object. It's easy enough to use an access value, but as unnecessary
use of access values is generally discouraged, I was just curious if
there was an alternative mechanism to achieve the desired effect.
> Consider two limited record types, inner and outer, with the former
> nested inside the latter. If the records are public, then code can
> initialize the outer by specifying an aggregate for the inner, as in:
> type Inner is limited
> record
> e : Integer;
> end record;
> type Outer is limited
> record
> i : Inner;
> end record;
> o : Outer := Outer'(i => Inner'(e => 42));
> However, if types are made private, suitable functions must be
> provided to make the appropriate objects. If just Inner is private,
> then this can be done (assuming simple creator functions that just
> create the objects with the given values):
> o : Outer := Outer'(i => Make_Inner(arg => 42));
> function Make_Outer (arg : Inner) return Outer is
> begin
> return Outer'(i => arg);
> end Make_Outer
> would end up trying to copy a limited type. For the cases in which an
> existing object is passed in, this would be the appropriate action,
> but for cases where the object is built-in-place into the argument,
> clearly the intended behavior is to build it in place to the resultant
> object. It's easy enough to use an access value, but as unnecessary
> use of access values is generally discouraged, I was just curious if
> there was an alternative mechanism to achieve the desired effect.
> -sb
Try this:
Function Make_Inner( I: Integer ) Return Inner is
begin
Return Result : Inner:= Inner'( E => I );
end Make_Inner;
Function Make_Outer( I: Integer ) Return Outer is
begin
Return Result : Outer:= Outer'( I => Make_Inner(I) );
end Make_Outer;
The 'trick' is to use all the parameters used in make_inner plus
whatever is needed in the Outer record for the parameter-list of
Make_Outer; thus you avoid all copying restrictions as you are really
building-in-place.
> On Feb 5, 4:03 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
> > Hi,
> > Consider two limited record types, inner and outer, with the former
> > nested inside the latter. If the records are public, then code can
> > initialize the outer by specifying an aggregate for the inner, as in:
> > type Inner is limited
> > record
> > e : Integer;
> > end record;
> > type Outer is limited
> > record
> > i : Inner;
> > end record;
> > o : Outer := Outer'(i => Inner'(e => 42));
> > However, if types are made private, suitable functions must be
> > provided to make the appropriate objects. If just Inner is private,
> > then this can be done (assuming simple creator functions that just
> > create the objects with the given values):
> > function Make_Outer (arg : Inner) return Outer is
> > begin
> > return Outer'(i => arg);
> > end Make_Outer
> > would end up trying to copy a limited type. For the cases in which an
> > existing object is passed in, this would be the appropriate action,
> > but for cases where the object is built-in-place into the argument,
> > clearly the intended behavior is to build it in place to the resultant
> > object. It's easy enough to use an access value, but as unnecessary
> > use of access values is generally discouraged, I was just curious if
> > there was an alternative mechanism to achieve the desired effect.
> > -sb
> Try this:
> Function Make_Inner( I: Integer ) Return Inner is
> begin
> Return Result : Inner:= Inner'( E => I );
> end Make_Inner;
> Function Make_Outer( I: Integer ) Return Outer is
> begin
> Return Result : Outer:= Outer'( I => Make_Inner(I) );
> end Make_Outer;
> The 'trick' is to use all the parameters used in make_inner plus
> whatever is needed in the Outer record for the parameter-list of
> Make_Outer; thus you avoid all copying restrictions as you are really
> building-in-place.- Hide quoted text -
> - Show quoted text -
This was my original plan, but the worry is that this doesn't reflect
the appropriate responsibilities; If A creates B and gives it to C,
then C should have no say in how (or if) it's created. For instance,
the Make_Outer code could easily alter the supplied arguments and
Make_Inner in any way it chooses. I suppose using an access value has
essentially the same problem, as it could simply eschew the supplied
value and allocate whatever it wants, but such is life I guess
> Consider two limited record types, inner and outer, with the former
> nested inside the latter. If the records are public, then code can
> initialize the outer by specifying an aggregate for the inner, as in:
> type Inner is limited
> record
> e : Integer;
> end record;
> type Outer is limited
> record
> i : Inner;
> end record;
> o : Outer := Outer'(i => Inner'(e => 42));
> However, if types are made private, suitable functions must be
> provided to make the appropriate objects. If just Inner is private,
> then this can be done (assuming simple creator functions that just
> create the objects with the given values):
> o : Outer := Outer'(i => Make_Inner(arg => 42));
> function Make_Outer (arg : Inner) return Outer is
> begin
> return Outer'(i => arg);
> end Make_Outer
> would end up trying to copy a limited type. For the cases in which an
> existing object is passed in, this would be the appropriate action,
> but for cases where the object is built-in-place into the argument,
> clearly the intended behavior is to build it in place to the resultant
> object. It's easy enough to use an access value, but as unnecessary
> use of access values is generally discouraged, I was just curious if
> there was an alternative mechanism to achieve the desired effect.
I think you have to decide: is an "Inner" an actual object that you
want to prevent copying of for some reason, or is it a collection of
components that you want to use to initialize an "Outer"? Something
seems wrong with your paradigm here.
(1) If an Outer actually contains an Inner, then you're trying to set
things up so that a program that uses this package will create an
Inner, and then create an Outer that contains a copy of the Inner.
But this contradicts the idea that Inner should be a limited type.
Limited types are for objects that you don't want to make copies of.
(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).
(3) If you want the ability for users to create an Outer that contains
some of the interesting data from an Inner, then maybe an Outer
shouldn't be thought of as containing an "Inner" as a component. In
that case, you may want to declare a new record type Inner_Data that
includes interesting information from an Inner, and make your Outer
contain this as a component instead of Inner.
(4) If you want Outer and/or Inner to refer to objects that can be
copied, they shouldn't be "limited"--and note that for untagged types,
you can declare a type to be limited in the visible part, and
nonlimited in the private part, so that you can do assignments in your
package body, but users of the package still can't make copies.
I don't know which one is the case without knowing more about the
actual application that you're trying to write. But in any event,
something seems wrong with the design.
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.)
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?
> 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.
On Mon, 6 Feb 2012 18:19:44 -0800 (PST), Simon Belmont wrote:
> 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.
I am afraid you should sacrifice both simplicity of use (if aggregates
could ever be considered "simple"), as well as information hiding.
The problem is that constructing functions of Ada are no replacement to
constructors, especially not with limited types. Multiple language hacks
were made (limited return, limited aggregates) in order to work this
around, but the problem persists. The issue you have is not the only one.
Another is when you have some parent types abstract. Since an abstract type
cannot be returned, you would have to implement partial constructors as
class-wide procedures and get a quite ugly and unsafe mess in the end.
There is no good advise how to approach this in general. You should try
this and that variant until you get a satisfactory solution.
On Tue, 07 Feb 2012 11:58:01 +0100, Georg Bauhaus wrote:
> On 07.02.12 10:10, Dmitry A. Kazakov wrote:
>> The problem is that constructing functions of Ada are no replacement to
>> constructors, especially not with limited types.
> Won't constructors have the same issue with limited private types
> and no copying?
The problem is specific to functions. A function returns a newly created
object, fully operational with all bells and whistles. This contradicts to:
1. limited types (non-copyable)
2. abstract types (no instances)
3. information hiding and partially operational objects
Constructor copies nothing. It is never called explicitly. No need to worry
about visibility issues. It does not promise or expose things which never
should come into existence (like creation of an abstract object). It does
not allocate memory, so it is much easier to roll back. It is much simpler
and, for all, a sound model which cannot be properly annotated with types.
Le Tue, 07 Feb 2012 14:25:40 +0100, Dmitry A. Kazakov
<mail...@dmitry-kazakov.de> a écrit:
> It is never called explicitly.
You have Controlled types.
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
On Tue, 07 Feb 2012 15:43:40 +0100, Yannick Duchêne (Hibou57) wrote:
> Le Tue, 07 Feb 2012 14:25:40 +0100, Dmitry A. Kazakov
> <mail...@dmitry-kazakov.de> a écrit:
>> It is never called explicitly.
> You have Controlled types.
Initialize is not a constructor:
1. Initialize is not enforced (a constructor is always called);
2. It can be called explicitly (a constructor is not an operation);
3. It can be overridden (a constructor is not a primitive operation);
4. It dispatches (a constructor is specific to its type);
5. Initialize has no additional parameters, it is useless in factories;
6. Initialize does not work with all types;
7. Initialize is called too early when tasks are components.
Like limited-valued functions Initialize is a hack, which cannot work
because construction cannot be expressed in terms of procedural model
decomposition.
Simon Belmont <sbelmont...@gmail.com> writes:
> Hi,
> Consider two limited record types, inner and outer, with the former
> nested inside the latter. If the records are public, then code can
> initialize the outer by specifying an aggregate for the inner, as in:
> type Inner is limited
> record
> e : Integer;
> end record;
> type Outer is limited
> record
> i : Inner;
> end record;
> o : Outer := Outer'(i => Inner'(e => 42));
> However, if types are made private, suitable functions must be
> provided to make the appropriate objects.
I'm not sure exactly what you're trying to do, but maybe something
like this would work:
function Make_Outer(Make_Inner: not null access function return Inner) return Outer;
You can pass "parameters" to the actual for Make_Inner by
making it nested so it can see whatever it needs.
