Re: Legit Warnings or not

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

On Wed, 3 Aug 2011 15:35:04 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net...
>> On Tue, 2 Aug 2011 16:30:24 -0500, Randy Brukardt wrote:
>>
>>> Either you are allowing changing the object to anything in the class,
>>> or you are not allowing it to be changed at all. No middle ground there.
>>
>> When I declare
>>
>>   type A is array (...) of S'Class;
>>
>> 1. Are all elements constrained to same specific type?
> 
> Assuming the model I'm suggesting is adopted, no.

But this is one of the most important use cases.

>> 2. May object types change after being initialized?
> 
> Yes. These are completely unconstrained entities.

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?

>> 3. Which rules apply to view conversions, e.g. T'Class (A (10)). Could it
>> be then assigned to which types, same, others?
> 
> The same rules as currently for a parameter of S'Class. I would not want to 
> make any changes there, the rules are messy enough as it is.

So S'Class, a component will have a different treatment than S'Class a
parameter? When passed to a subprogram it suddenly becomes constrained?

>> 5. I am horrified what kind of "accessibility rules" might get invented for
>> passing elements of this "array" here and there.
> 
> For me, (dynamic) accessibility is a waste of time; it adds overhead, adds a 
> failure hazard, and buys nothing in terms of safety. (I have to use 
> 'Unchecked_Access in 99% of my programs; 'Access fails for one reason or 
> another.)

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.

IMO, all constraints must be explicitly stated as proper subtypes. Only
this would exclude a need in accessibility rules, but it also would your
approach. If you want an unconstrained S'Class as a component (or whatever)
you have to have a special *static* supertype for this, e.g. S'Class(<>).
Then you could deal with that in some sane way.

>> [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.

>>> And there is no "control over copying". These are normal "parts" of the
>>> object, and they're always copied. If you don't want copying, then you need
>>> to use some sort of reference (cursor or access type). (Of course, an
>>> implementation can always do an "as-if" implementation, but the model is
>>> always deep copying.)
>>
>> Which would make the compiler implementation unusable in so many cases.
> 
> If so, you would be abusing the intent of the feature. It's intended for 
> composition uses only; if you need to represent dynamically changing 
> connections between objects, then you clearly need references of some sort 
> (cursors preferrably, access types otherwise). If, however, you are 
> statically combining objects, then having to manage references explicitly is 
> just busywork -- it harms readability, does nothing for performance, and the 
> like. Obviously, there is a gray area between these -- but you would never 
> to use direct components to represent connections, only composition. 
> Otherwise you are hiding structure; I'm only interested in cases where there 
> is only one object whose parts consist of previously existing objects that 
> will lose their independent identity.

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!

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