Re: Interesting effects in array renaming

[Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Georg Bauhaus wrote:
: 
:> I don't think it is so bad, it is much more an issue of what
:> renaming means, maybe?
: 
: No, it is an issue of which meaning has an explicit specifying of a subtype. 

Hm. 

  procedure foo(a: Apple) is
     p: Orange renames a;

may be correct, but confusing. Because, in my view a least, the
programmer is violating the usual meaning of "renames".
I think the bias is towards the wrong side/word if "Orange"
outweighs "renames".


:> Most prominently, you give another name
:> to an entity, you don't make a new entity.
: 
: Really? To me a "view" is definitely an "entity". You probably mean that 
: renaming should not create a new object.

Yes.

: But it is no matter, imposing a 
: constraint on an existing object does not change the object. It is merely a 
: precondition.

Should renaming be for imposing constraints?
If I rename myself as Bouwhouws, that won't change me I think,
and it doesn't impose a constraint on me. That's renaming for me.
It won't even change the sound of my name ;-)

: for I in Constrained'Range loop
:   X2 (I) := 0;
: end loop;
: 
: may raise Constraint_Error or else corrupt memory if range checks are 
: suppressed. It is abolutely unacceptable. To put it in one sentence: either 
: you change bounds or you check them.

But if you declare a subtype with constraints to be used in a renaming
declaration, then you know the constraints. You also know the bounds of
objects involved, by way of attributes. So you could make your intention
more explicit by using these known quantities if you want to avoid
copying.


-- sb463ba