Re: Run-time accessibility checks

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1xgim3qybjw07$.16nw9986hywhh.dlg@40tude.net...
...
> 2. The variant you didn't like uses no access types
>
>   Op (C, I)
>
> but requires C to inherit a modified interface of its elements. I see
> nothing wrong with that.

This isn't inheritance, as it requires adding a selector of some sort (you 
called it an index, Ada calls it a cursor) to the operations. At best, it is 
some sort of automatic synthesis of operations. But that again begs the 
question of how to describe what it does -- I don't see any reasonable way 
to do that. (How can you dispatch to an operation that has a different 
number of parameters???)

...
...
>> [I'm also not seeing your messages for some
>> reason, had to grab this one off of Google Groups.]
>
> Is your mail reader in Ada? (:-))

No, unfortunately. I don't have time to write a mail reader... compiler, web 
server, and mail server seem like enough of "build-your-own". :-)

...
>> You're solving the wrong problem. (Yes, I did read the rest of the 
>> message
>> before replying here.) There is no problem with overriding the top-level
>> assignment operation, never has been. The problem is composition (which 
>> is
>> necessary so that the invariants of an abstraction are preserved). A
>> component does not know nor care about the discriminants of the object 
>> that
>> it is a component of. And it could not, in general, or again you have
>> descended into madness (no type can enumerate all of the places it could
>> possibility be used).
>
> But discriminants leak anyway. You cannot have an unconstrained component
> without passing its constraint in some form to the container. If that is a
> broken abstraction, then it is already broken by someone else. The
> container type knows its actual components and assigns them. What else
> composition is needed?

You're claiming that every type that has a component of a type with 
user-defined assignment also must have a user-defined assignment? That's way 
too much work, and way too likely to get wrong.

>> You've called that abstraction an index, but it is the exact same 
>> abstraction.
>
> The difference can be illustrate on:
>
>   A (I) = B (I)
>
> The index value I applies to any container that uses it, independently on
> the container content. You can have an index without any container:
>
>   for I in 1..200 loop
>       Put_Line ("Hallo!");  -- No any containers in sight
>   end loop;
>
>> And it would need the exact same rules
>> for updates and the like, giving the same effects that you don't like.
>
> No, it is not an error to do anything with the container while thinking
> about "the second element of." Cursor and index are fundamentally 
> different
> things. Indices do not persist, they do not require identity of the 
> element
> etc.

That seems much more limiting than the cursor idea. It doesn't make any 
sense to talk about the "second" item of a (generic) container. Consider a 
map referenced by strings, for instance. Moreover, elements of many forms of 
container don't have any order, so you can't do anything useful with the 
index by itself -- but operations like iteration are still meaningful.

                                      Randy.