lambda

[Antoon Pardon]

Op 2005-01-18, David Bolen schreef <db3l at fitlinxx.com>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>
>> Op 2005-01-18, Simon Brunning schreef <simon.brunning at gmail.com>:
>> > On 18 Jan 2005 07:51:00 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>> >> 3 mutating an item in a sorted list *does* *always* cause problems
>> >
>> > No, it doesn't. It might cause the list no longer to be sorted, but
>> > that might or might no be a problem.
>> 
>> Than in the same vain I can say that mutating a key in a dictionary
>> doesn't always cause problems either. Sure it may probably make a
>> key unaccessible directly, but that might or might not be a problem.
>
> Well, I'd definitely consider an inaccessible key as constituting a
> problem, but I don't think that's a good analogy to the list case.
>
> With the dictionary, the change can (though I do agree it does not
> have to) interfere with proper operation of the dictionary, while a
> list that is no longer sorted still functions perfectly well as a
> list.

I think we are talking past each other. I'm talking about the concept
the programmer has in his mind. If the prgrammer has a sorted list in
his mind and an element in that list gets mutated that *does* *always*
cause problems. I'm not talking about a list in which the elements
happen to be in a particular order, but about a list that will be given
to algorithms that depend on the list being ordered.

> That is, I feel "problems" are more guaranteed with a
> dictionary since we have affected base object behavior, whereas sorted
> is not an inherent attribute of the base list type but something the
> application is imposing at a higher level.

But if the program uses one of the buildin sorts, isn't it then obvious
that this is an inherent attribute we want to impose? So is sorting
a list with mutable object not also more guaranteed to cause problems.
So shouldn't we limit the sort algorithms to containers with immutable
elements?

> For example, I may choose to have an object type that is mutable (and
> not worthy for use as a dictionary key) but maintains a logical
> ordering so is sortable.  I see no problem with sorting a list of such
> objects, and then walking that list to perform some mutation to each
> of the objects, even if along the way the mutation I am doing results
> in the items so touched no longer being in sorted order.  The act of
> sorting was to provide me with a particular sequence of objects,

Personnaly I don't see what the sorting was good for in this case.
And I think such programming might be slightly dangerous if you
cooperate with other people. They may not understand the particular
nature of your mutation and rely on the fact that your list has been
sorted to conclude that it still is sorted.

> but
> aside from that fact, the list continues to perform perfectly well as
> a list even after the mutations - just no longer delivering objects in
> sorted order.

Which may be a problem for those who rely on it.

-- 
Antoon Pardon