Extension of non-limited type needs limited component 
Author Message
 Extension of non-limited type needs limited component

How do I extend a non-limited tagged type to add a limited component?

Mike



Sun, 01 May 2005 18:03:19 GMT  
 Extension of non-limited type needs limited component



Quote:
> How do I extend a non-limited tagged type to add a limited component?

You can't. Make the original type limited.
The whole hierarchy has to be limited (or not limited, excluding adding a
limited element). The reason is that otherwise, you could end up trying to
assign a variable with a limited component.

--
---------------------------------------------------------

Visit Adalog's web site at http://www.adalog.fr



Sun, 01 May 2005 20:06:15 GMT  
 Extension of non-limited type needs limited component

Quote:

> How do I extend a non-limited tagged type to add a limited component?

You don't.  ;-)  You can extend it with a pointer-to-limited component,
however.  But your best bet may be to make the non-limited type
limited.  Or make the component non-limited.

- Bob



Sun, 01 May 2005 22:28:28 GMT  
 Extension of non-limited type needs limited component
I wrote

Quote:
> > How do I extend a non-limited tagged type to add a limited component?

Jean-Pierre Rosen replied

Quote:
> You can't. Make the original type limited.
> The whole hierarchy has to be limited (or not limited, excluding adding a
> limited element). The reason is that otherwise, you could end up trying to
> assign a variable with a limited component.

Unfortunately I can't make the base type limited as it is a generic
gui dialog base 'class'.

I understand that I would need to make the extended type limited to
avoid the possible assignment to the limited component, but I cannot
see why I should have to make the whole hierarchy limited.

How can assignment by upcasting the extended type possibly affect the
limited component?

Regards,

Mike



Mon, 02 May 2005 17:26:08 GMT  
 Extension of non-limited type needs limited component
I wrote

Quote:
> > How do I extend a non-limited tagged type to add a limited component?

Robert A Duff replied

Quote:
> You don't.  ;-)  You can extend it with a pointer-to-limited component,
> however.  But your best bet may be to make the non-limited type
> limited.  Or make the component non-limited.

Unfortunately neither the base type nor the limited component are
under my control.
I have thought about the pointer-to-limited option but find that there
is no pointer type declared in the package that declares the limited
type and consequently there are no operations on the limited type that
take a pointer type.
Am I allowed to create my own pointer-to-limited type and de-reference
it for use later? Wouldn't the act of de-referenceing be an implicit
assignment?

Regards,
Mike.



Mon, 02 May 2005 17:33:55 GMT  
 Extension of non-limited type needs limited component

Quote:

> Am I allowed to create my own pointer-to-limited type and de-reference
> it for use later?

Yes. This enshures the locality of the pointer use. That's why it's Ada
style to not provide pointers in the base packets.

Quote:
> Wouldn't the act of de-referenceing be an implicit assignment?

No.


Mon, 02 May 2005 17:35:25 GMT  
 Extension of non-limited type needs limited component
Quote:
----- Original Message -----

Newsgroups: comp.lang.ada

Sent: November 14, 2002 3:26 AM
Subject: Re: Extension of non-limited type needs limited component

> I wrote

> > > How do I extend a non-limited tagged type to add a limited component?

> Jean-Pierre Rosen replied

> > You can't. Make the original type limited.
> > The whole hierarchy has to be limited (or not limited, excluding adding a
> > limited element). The reason is that otherwise, you could end up trying to
> > assign a variable with a limited component.

> Unfortunately I can't make the base type limited as it is a generic
> gui dialog base 'class'.

> I understand that I would need to make the extended type limited to
> avoid the possible assignment to the limited component, but I cannot
> see why I should have to make the whole hierarchy limited.

> How can assignment by upcasting the extended type possibly affect the
> limited component?

Since the purpose of "limited" is to prevent having multiple copies of the
same object (e.g. an object of Ada.Text_IO.File_Type) wherein changing the
state of one of the copies is changed (e.g. by closing the file in the
previous example) would leave the other copy in an incorrect state,
allowing limited components in a non-limited record would violate this
principle.

On the other hand, if multiple access objects are used to designate the
same limited object, then changes to the state by reference through one
of the access objects will be reflected in all of the access objects
designating that limited object.

Of course, the specifier of a limited type may provide a Copy procedure
(e.g., with a declaration like
procedure Copy (From : My_Limited_Type; To : out My_Limited_Type);
In that case, the fact that use of a Copy procedure is required, rather
than a simple assignment, makes the user of the type aware, that he
is creating a new distinct object, not a new reference to an existing
object.



Mon, 02 May 2005 19:43:47 GMT  
 Extension of non-limited type needs limited component



Quote:
> How can assignment by upcasting the extended type possibly affect the
> limited component?

Consider:

   X : T'class := Some_Dynamic_Function (1);
   Y : T'class := Some_Dynamic_Function (2);
begin
   X := Y;

At compile time, we know nothing about the specific type of the values in X
and Y, but assuming that T is not limited, the assignment is allowed. If X
and Y happen to have different tags at run time, the assignment will raise
Constraint_Error, but that's all.

If you were allowed to extend T with limited components, you would
effectively copy the limited components!

--
---------------------------------------------------------

Visit Adalog's web site at http://www.adalog.fr



Mon, 02 May 2005 20:33:07 GMT  
 Extension of non-limited type needs limited component
On Thu, 14 Nov 2002 13:33:07 +0100, "Jean-Pierre Rosen"

Quote:



>> How can assignment by upcasting the extended type possibly affect the
>> limited component?

>Consider:

>   X : T'class := Some_Dynamic_Function (1);
>   Y : T'class := Some_Dynamic_Function (2);
>begin
>   X := Y;

>At compile time, we know nothing about the specific type of the values in X
>and Y, but assuming that T is not limited, the assignment is allowed. If X
>and Y happen to have different tags at run time, the assignment will raise
>Constraint_Error, but that's all.

>If you were allowed to extend T with limited components, you would
>effectively copy the limited components!

An LSP violation to put it short.

Which also raises an interesting question, whether T'Class should
always inherit "non-limitness" of T. Or more generally shouldn't one
have an ability to disallow primitive operations (like ":=" in case of
non-limited->limited mutation)?

Let we allow disallowing, then either

1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise
an exception and so refuse to copy the limited components.

2. ":=" is class-wide in the right parameter, then it will dispatch
somewhere within its body and again an exception will happen if an
attempt to copy a limited component will be made..

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de



Mon, 02 May 2005 22:27:11 GMT  
 Extension of non-limited type needs limited component

Quote:
>Which also raises an interesting question, whether T'Class should
>always inherit "non-limitness" of T. Or more generally shouldn't one
>have an ability to disallow primitive operations (like ":=" in case of
>non-limited->limited mutation)?

Of course, Ada has the capability to disallow ":=". It's called (drum
roll) "limited". :-)

This issue was discussed extensively during the Ada 95 design process.
It seems like some way to disallow ":=" is needed, but we kept coming
back to the point that that is what "limited" is for. We certainly don't
need two notions of no ":=".

Quote:
>...
>1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise
>an exception and so refuse to copy the limited components.

I don't know why this wasn't chosen. It seems better on the surface.
Possibly because of the desire to catch errors at compile-time rather
than run-time.

However, that still doesn't solve the problem that we had in Claw. What
we wanted was a limited root window type with non-limited (thus
assignable) controls. That is, something like:

      Root_Window_Type (limited controlled)
           Basic_Window_Type (limited)
           Root_Dialog_Type (limited)
                Modal_Dialog_Type (limited)
          Root_Control_Type (non-limited)
                Edit_Type (non-limited)
                Checkbox_Type (non-limited)
                Static_Text_Type (non-limited)

[We want to be able to copy control objects because our goal was "no
visible pointers required" for the interface.]

This does not have the classwide assignment problem, because only
Root_Control_Type has ":=", so it isn't possible to dispatch to a
limited type's ":=".

We ended up making the whole hierarchy non-limited, but this means
implementing assignment for types for which is both a lot of work and
unneeded (such as application windows). Worse, we didn't meet our "no
pointers" goal, because we can't put limited objects into extentions of
application windows. (So you have to use pointers to do that.)

I don't recall why you are not allowed to make the extension of the
limited type non-limited. (I didn't find anything in the AARM on this
subject.)

                   Randy Brukardt



Tue, 03 May 2005 03:25:13 GMT  
 Extension of non-limited type needs limited component

Quote:

> Am I allowed to create my own pointer-to-limited type and de-reference
> it for use later?

Yes.  You just need to say ".all" whenever you want to call the
preexisting procedures.

The only problem with using a pointer that then you have to worry about
storage management.  You'll probably end up allocating the thing in the
heap (with "new"), and then you have to worry about deallocating it.

Quote:
>... Wouldn't the act of de-referenceing be an implicit
> assignment?

No.  "X.all" returns the heap object that the pointer points at.
It does not fetch the value out of that object.  The fetch operation is
really what limited types want to disallow.

When you say P(X.all), the heap object will be passed by reference if it
is really limited -- no copy is made.

- Bob



Tue, 03 May 2005 05:41:29 GMT  
 Extension of non-limited type needs limited component

Quote:

> How can assignment by upcasting the extended type possibly affect the
> limited component?

If you have "type T2 is new T1 with...", then it is important that if T2
is limited, then T1'Class must also be limited, because ":=" on T1'Class
objects will copy the T2 part, if the objects' tag happens to be T2'Tag.

In Ada, T1'Class is limited if and only if T1 is limited.
So that means the whole hierarchy of tagged types has to be
either limited or nonlimited.  I'm not sure if it would cause semantic
troubles to allow a nonlimited T1 with a limited T1'Class (assuming one
could invent some syntax for saying so).  Interesting question.

- Bob



Tue, 03 May 2005 07:39:38 GMT  
 Extension of non-limited type needs limited component

Quote:
> Which also raises an interesting question, whether T'Class should
> always inherit "non-limitness" of T. Or more generally shouldn't one
> have an ability to disallow primitive operations (like ":=" in case of
> non-limited->limited mutation)?

> Let we allow disallowing, then either

> 1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise
> an exception and so refuse to copy the limited components.

Compile time errors are good.  Exceptions (run-time errors) are evil.
This is not Smalltalk, where you can dispatch to a method that does not
exist.

- Bob



Tue, 03 May 2005 08:30:03 GMT  
 Extension of non-limited type needs limited component
On Thu, 14 Nov 2002 13:25:13 -0600, "Randy Brukardt"

Quote:



>>Which also raises an interesting question, whether T'Class should
>>always inherit "non-limitness" of T. Or more generally shouldn't one
>>have an ability to disallow primitive operations (like ":=" in case of
>>non-limited->limited mutation)?

>Of course, Ada has the capability to disallow ":=". It's called (drum
>roll) "limited". :-)

>This issue was discussed extensively during the Ada 95 design process.
>It seems like some way to disallow ":=" is needed, but we kept coming
>back to the point that that is what "limited" is for.

In an OO language like Ada 95 is, "limited" makes little sense,
because it covers only one of many useful alternatives.

Quote:
>We certainly don't need two notions of no ":=".

But there are indeed multiple notions of ":=". Let ":=" is exposed as
a normal operation. Then two arguments would give us 4 different
variants [without much thinking about how useful are some of them]:

procedure ":=" (Left : in out T; Right : T);
procedure ":=" (Left : in out T'Class; Right : T);
procedure ":=" (Left : in out T; Right : T'Class);
procedure ":=" (Left : in out T'Class; Right : T'Class);

Same is valid for all operations with several parameters. For
instance, the predefined "=" (Left, Right : T), which cannot be
disallowed with a disastrous result that a user-defined "=" (Left : T;
Right : T'Class) gets overloaded with the predefined one.

Quote:
>>1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise
>>an exception and so refuse to copy the limited components.
>I don't know why this wasn't chosen. It seems better on the surface.
>Possibly because of the desire to catch errors at compile-time rather
>than run-time.

Yep, LSP again. However, nobody cares about LSP in case of

   X : Positive;

which also shamefully violates LSP and leads to a run-time exception,
should -1 happen to be assigned to X.

Quote:
>However, that still doesn't solve the problem that we had in Claw. What
>we wanted was a limited root window type with non-limited (thus
>assignable) controls. That is, something like:

>      Root_Window_Type (limited controlled)
>           Basic_Window_Type (limited)
>           Root_Dialog_Type (limited)
>                Modal_Dialog_Type (limited)
>          Root_Control_Type (non-limited)
>                Edit_Type (non-limited)
>                Checkbox_Type (non-limited)
>                Static_Text_Type (non-limited)

>[We want to be able to copy control objects because our goal was "no
>visible pointers required" for the interface.]

BTW. Why do not we have constant record members in Ada? Maybe because
there is no true contructors with parameters?

Quote:
>This does not have the classwide assignment problem, because only
>Root_Control_Type has ":=", so it isn't possible to dispatch to a
>limited type's ":=".

>We ended up making the whole hierarchy non-limited, but this means
>implementing assignment for types for which is both a lot of work and
>unneeded (such as application windows). Worse, we didn't meet our "no
>pointers" goal, because we can't put limited objects into extentions of
>application windows. (So you have to use pointers to do that.)

This is an opposite this = defining new operations. It should be a
lesser problem (for LSP).

Quote:
>I don't recall why you are not allowed to make the extension of the
>limited type non-limited. (I didn't find anything in the AARM on this
>subject.)

A need to generate some predefined assignment?

The whole idea of "limitness" is IMO wrong. Let's expose ":=", default
constructor, copy constructor to the programmer and let he have a
headache! (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de



Tue, 03 May 2005 18:04:38 GMT  
 Extension of non-limited type needs limited component
On Fri, 15 Nov 2002 00:30:03 GMT, Robert A Duff

Quote:


>> Which also raises an interesting question, whether T'Class should
>> always inherit "non-limitness" of T. Or more generally shouldn't one
>> have an ability to disallow primitive operations (like ":=" in case of
>> non-limited->limited mutation)?

>> Let we allow disallowing, then either

>> 1. ":=" should dispatch in X:=Y to a disallowed operation, thus raise
>> an exception and so refuse to copy the limited components.

>Compile time errors are good.  Exceptions (run-time errors) are evil.

Absolutely

Quote:
>This is not SmallTalk, where you can dispatch to a method that does not
>exist.

Sure? And what about this:

type A is tagged ...
procedure Foo (L, R : A);

type B is new A with ....

X : A'Class := Some_A;
Y : A'Class := Some_B;

Foo (X, Y); -- Oops, dispatching to nowhere!

[ Not that I argue for SmallTalk, of course (:-)) ]

Then disallowing is already allowed for non-tagged types =
"is abstract".

Further one can always override with a subroutine that throws
Program_Error. Is that better? IMO it is the same. The only real
difference is that one cannot get rid of overloading of the undesired
operation. What is actually required. I think that there could be
situations where it would be useful to disallow an operation in the
public interface and to override it with something working in the
private one.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de



Tue, 03 May 2005 18:22:50 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Subtype of limited type non-limited?

2. limited/non-limited in Ada95

3. Limited Type Types

4. <union-type>, <limited-type>

5. Resume about a range limit over a three component key problem

6. Resume about a range limit over a three component key problem

7. Done with range limit over three component key!!! :-)

8. Help with range limit over a three component key (CFW2003)

9. Help with range limit over a three component key

10. Where to find tcl/tk Tkinter component memory limits

11. File Manager 2 limits And CFW4b (non-ABC)

12. smallest non-zero number (and other limits)

 

 
Powered by phpBB® Forum Software