Re: Run-time accessibility checks

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

On Tue, 16 Dec 2008 16:21:00 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:k2ftogbqmojg.yrjw3ldbi604.dlg@40tude.net...
> ...
>>> 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.
>>
>> No, if index is unordered and not dense, then iteration is meaningless. It
>> is a broken abstraction then. If you want to iterate a container you have
>> to order its elements. That is equivalent to existence some ordered dense
>> index of.
> 
> Not at all. You are saying that "forall" (that is, do something to all 
> elements of a container) is not a useful iteration if the elements don't 
> have an order. That's pretty hard to believe; indeed, the value of an 
> iterator is is specifically because the order of the elements is not 
> specified; without that, there is no way to get all of the elements via 
> their cursors (or indexes, if you prefer).

Well, that is a philosophic-mathematical issue. I am on a constructivist's
position here. You cannot say "forall," without constructing a set in a way
that effectively enumerates its elements, which in turn is equivalent to a
contract on the set and the corresponding (there can be many) index of.
Clearly any set in a computer has such property, but it breaks abstraction.

>> The index can be of the type System.Address, that is no matter.
>> But to be able to iterate is a contract on the container. It is IMO a very
>> bad idea to assume all containers to fulfill this contract.
> 
> I would never want to say *never* (there is always a counter-example), but 
> surely all of the classic containers (including a "bag") need iteration. 
> It's true that the implementation of a "bag" will necessarily impose an 
> order on the elements, but that order is not interesting and shouldn't be 
> considered part of the abstraction. But the ability to get all elements of a 
> bag for processing is a fundamental operation of the container.

That is not a bag then. Consider an implementation of a bag that uses an
RDB as the store. You cannot iterate rows in an RDB. You can do only ones
of a result set. These are different sets, and the second set has an
extremely heavy penalty to build from the first (potentially
Storage_Error). Not providing iteration would be important for safe use.

But I don't see how this all can be an argument for cursor against index.
If the primary index is unordered that does not mean you cannot have
another one ordered. You can provide as many views of the container you
wished. If you want to iterate container in a loop, provide a view on it as
an array indexed by Positive. As simple as that.

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