Re: Legit Warnings or not

["Randy Brukardt" <randy@rrsoftware.com>]

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

> 2. May object types change after being initialized?

Yes. These are completely unconstrained entities.

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

> 4. In which relation are slices of the array and arrays of T'Class when T
> is related to S? [Classes of arrays vs. arrays of classes vs. classes of
> arrays of classes etc.]

Nothing special; there is no attempt to address the issues with inheritance 
of composition. I don't think those issues *can* be addressed in an Ada-like 
type system.

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

But that's irrelevant; no new accessibility would be needed because there is 
no new capability here. These are exactly the same as mutable discriminanted 
objects (i.e.the type has defaults for the discriminants). It would be 
erroneous to change the tag of a statically bound parameter (just like it is 
erroneous to change the discriminant in such a case) -- there is no way to 
avoid that without requiring programmers to effectively ignore all 
constraints (because they could change), which is too bogus of a model to 
contemplate.

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

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

                            Randy.