Re: Copy vector in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 5 Nov 2012 00:50:25 -0800 (PST), Maciej Sobczak wrote:

> W dniu poniedzia�ek, 5 listopada 2012 09:31:13 UTC+1 u�ytkownik Dmitry A. Kazakov napisa�:
> 
>>> It is not "clearly" to me. Assigning Rectangles to Triangles does not make any sense.
>> 
>> Does the example presume that both are in the same hierarchy of types, e.g.
>> "shape"? Whether assignment makes sense depends on that.
> 
> You can always imagine arbitrary meanings of "assignment" and implement it, like:
> 
> D : Date;
> 
> D := "tomorrow";
> 
> But we are diverting from the subject of whether limitedness and
> assignment are supported consistently and orthogonally to other language
> features.

Then it was you who tried. My point was that assignment, or better to say,
copy constructor (from which assignment is deduced), is a
doubly-dispatching "operation." It is not orthogonal and cannot be.

There are lots of further questions about special treatment of copy
constructors, like whether one could introduce them later, e,g, promoting
limited types to non-limited and demoting back. These should be considered
in the larger context of disallowing operations, subtracting interfaces
etc. But the starting position is independent on that.

>>> I also mean what the programmer might possibly provide - Rectanges vs. Triangles and so on.
>> 
>> He will replace a triangular shape with a rectangular one.
> 
> Wrong. The existing alias of Trangle'Class will break.

What is alias?

As for "breaking" anything, that is technically speaking substitutability.
Substitutability is an issue if and only if, you inherit. Once the
programmer overrides or is forced to override there is no issue of
substitutability and there is no breaking. If you say that the programmer
could not implement the overridden operation without violation of some
semantic constraints that is another issue, not a language business, except
for checking static contracts. The programmer must then choose another type
hierarchy design, but that is outside the language scope.

>> You make some assumptions about the semantics of
>> assignment, which may or may not hold. Again, it is not the language
>> business.
> 
> Yes. Let's agree that the language should allow this possibility.
> We are still diverting from the subject of whether the existing solution
> is elegant and orthogonal with respect to other language features.

Neither elegant, nor orthogonal. Both languages did it wrong.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de