jastrachan | 30 Mar 17:02 2005
Picon

Re: thoughts about the Range concept

Note that List is an interface and also that a List can be immutable. 
e.g. see Collections.unmodifiableList(list)

So I see Range as a sub-type of List which is also immutable; once 
created, its got a well defined upper & lower bound and cannot be 
modified. Other than that, I pretty much agree with every point in this 
thread

On 29 Mar 2005, at 09:24, Dierk Koenig wrote:

> Hi Martin,
>
> thanx for your answer.
>
> I agree to all you said for the case of IntRanges.
>
> My puzzles come with self-made ObjectRanges or even
> Float Ranges.
>
> Does (0.0..1.0) contains 0.99 ?
> Sure, when a Range is defined by its bounds.
> Not so sure, when it is a List. When List determines the
> semantic of Range, then it also determines the meaning
> of contains(). I.e. Ranges contain, what the underlying
> List contains. For the above example, it depends on
> how next() behaves on Float.
>
> In other words:
> - next() can be used to construct the underlying
>   List and contains() is list.contains(), or
> - next() can be used for 'each' only and contains()
>   barely uses the bounds for checking.
>
> In the first case, Range is a List.
> In the latter, Range is not a List.
>
> As long as Ranges are Lists, I see not efficient way
> of implementing consistent ObjectRanges.
>
> ..
>> It's extremely handy for ranges be used wherever a list can be used, 
>> and
>> to have the same semantics.
> ..
>>> If it was, it would need to support +,-,*, and << like Lists do,
>>> not imposing harder constraints. But applying the operators can
>>> lead to non-continuous Ranges which makes no sense to me, e.g
>>> ((1..2) + 4).contains(3) // ???
>>
>> If a Range is essentially an efficient subtype of a list, then (1..2) 
>> +
>> 4 has a meaning forced on it from lists.
>
> .. which would be:
> assert ((1..2) + 4).contains(3) == false
> since
> assert [1,2,4].contains(3) == false
>
> Thus we allow discontinuous Ranges.
>
> Thus we cannot determine contains() effectively by
> evaluating the bounds.
>
> I may be a bit biased by the Range implemention in Ruby,
> but I think its not totally weird to see an implementation
> and a conceptual issue here.
>
> cheers
> Mittie
>
> P.S. I see your point about efficient sublists. Maybe there is
> a different concept beside Ranges that can help:
> "Index Collection" or so.
>
>

James
-------
http://radio.weblogs.com/0112098/


Gmane