Re: Legit Warnings or not

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

On Fri, 5 Aug 2011 18:57:43 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 

>> Unconstrained to S'Class?
>>
>>   type S is new T with ...;
>>   type A is array (1..1) of S'Class;
>>   X : T;
>>   Y : A;
>> begin
>>   T'Class (Y (1)) := X; -- Is this OK?
> 
> No, of course not. Unconstrained to S'Class is right.

[...]
>> So S'Class, a component will have a different treatment than S'Class a
>> parameter? When passed to a subprogram it suddenly becomes constrained?
> 
> Huh? The only time S'Class is "constrained" is when it is a constant.

[...]
>> Right, accessibility rules is an evil, but if you allow unconstrained
>> S'Class, actually implicitly constrained to something somewhere, then these
>> implicit constraints must be handled somehow, and there is no other way to
>> do this than by accessibility rules.
> 
> I don't see any implicit constraints. If there are any, they ought to be 
> eliminated.

Then:

   procedure Carcinogenic (X : in out T'Class) is
      Y : T;
   begin
      X := T;
   end Carcinogenic;

   Z : S'Class; -- Constrained to S'Class?
begin
   Carcinogenic (T'Class (Z)); -- Ignore the constraint!

[ Your idea is to make all classes subtypes of some huge dynamic type. This
is not a workable type model as so many OOPLs already showed. ]

>>>> [The behavior of types upon composition is a very non-trivial issue.]
>>>
>>> I would not make any change there; to the extent that it is a problem now it
>>> would stay that way.
>>
>> But you have to address it in array slices and in all other rules
>> concerning type and subtype equivalence. You could ignore them for T vs. S,
>> because these are different types, but you cannot do this for differently
>> constrained class-wide subtypes, e.g. S'Class(<>) vs. S'Class + fixed tag.
> 
> "Fixed tag"? No such thing for a variable. (And the rules for constants 
> handle the other cases.) My entire point is that there are no constrained 
> class-wide subtypes.

You must have them constrained in order to honor type-specific arguments
passed to class-wide operations:

   Z : S;
begin
   Carcinogenic (Z);

When you lift a constraint, you have to check it dynamically. Compare:

   procedure Foo (X : in out String) is
   begin
      X := "abc";
   end Foo;

   Z : String (1..80);
begin
   Foo (Z);

>> I mean the cases of composition sharing components. I don't know how usable
>> the new "aliased" parameter subtype in Ada 2012 is, but presently there is
>> a big problem of getting rid of unnecessary copying. All container
>> implementations try to eliminate this overhead. In my view on the language
>> design it is OK, because the type system must be small, but have flexible
>> interfaces. Your approach is the opposite, clumsy interfaces, much
>> manipulation behind them. But where is the promised performance? Nowhere,
>> huge S'Class are intended to be copied on any occasion!
> 
> What promised performance? If you don't want the components to be copied, 
> then they can't be components! That's been True in Ada since the beginning, 
> and I can't imagine trying to change that.
> 
> But performance doesn't matter to 90% of the code; readability, 
> maintainability, and the avoidance of errors are much more important.

Right, then your argument that the compiler could do something better than
the programmer was invalid.

> Requiring the user to manually create, copy, and destroy objects is far more 
> error prone than building it into the language.

Right, but the language forces manual manipulation, because interface and
implementation are not properly separated. The developer of a type must
expose all dirty washes to the user.

> (This is the same reason why 
> I am so strongly opposed to having any access types in the interface of an 
> object.)

Again, right, but this requires means to enforce identity semantics in the
interfaces.

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