Two small points of feedback

[Zhong Yu]

On Fri, Jan 4, 2013 at 10:49 AM, Bruno P. Kinoshita <kinow at apache.org> wrote:
> Hi all!
>
> First message here, I'm trying to follow what's been discussed in the list first and learn as much as possible with lambda-dev before continuing to write code in Apache Commons Functor component - a functional programming API for Java.
>
> However, some months ago I had similar problem in [functor]] with Ranges, and after thinking for a while, and playing with Python, R, Haskell and Java API's, like Guava, I proposed in a branch [1] a solution for the ranges.
>
> In this case we would have an option to have inclusive or exclusive ranges. The default behaviour of ranges in [functor] was range(inclusive, exclusive). The problem with this was that I needed at the time a range of characters. And the most obvious way of representing a range of chars from a to z was range('a', 'z').

range 'a'-'z' is a very nice use case for the inclusive style.

how about range(from, inc(to)), where inc(x)==x+1. ha!

>
> Well, in order to build a generic API for all kinds of users, and as Guava had the same kind of parameters for defining the bound types, the proposed branches had support for both types, but the default behaviour was kept (inclusive, exclusive). So in my case I used a range('a', BoundType.Inclusive, 'z', BoundType.Inclusive).
>
> Just my 0.02 cents
>
> BTW, I just found out about this mailing list, and I'm learning a lot with all the discussions. Kudos for the great work.
>
> BR,
>
> [1] http://svn.apache.org/viewvc/commons/proper/functor/branches/generators-FUNCTOR-14/src/main/java/org/apache/commons/functor/generator/range/
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
>>________________________________
>> From: Zhong Yu <zhong.j.yu at gmail.com>
>>To: Stephen Colebourne <scolebourne at joda.org>
>>Cc: lambda-dev <lambda-dev at openjdk.java.net>
>>Sent: Friday, January 4, 2013 2:37 PM
>>Subject: Re: Two small points of feedback
>>
>>Is "inclusive" range very useful in Java ecosystem? Maybe for simple,
>>literal ranges; for other cases it's probably clunkier
>>
>>    rangeInc(off, off+len-1)  vs rangeExc(off, off+len)
>>
>>"Exclusive range" probably should be the default since it's the
>>established convention, it interoperates well with other codes, and
>>won't cause problems for any C-family programmers.
>>
>>If someone writes a literal range like rangeInc(1,10), instead of
>>rangeEx(0,10), he's probably not observing the convention, and he'll
>>soon run into problems with the rest of Java world.
>>
>>(I'm even against providing an option for inclusive range; converting
>>between inclusive/exclusive ranges is something that should be very
>>simple, yet somehow is disorienting to human minds, like daylight
>>saving time transition. Life is simpler if everybody sticks to 1
>>convention)
>>
>>Zhong Yu
>>
>>On Fri, Jan 4, 2013 at 9:49 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
>>> On 4 January 2013 15:05, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>>> My theory is that its because the numbers are discrete. "From Monday
>>>>> to Wednesday" is closed in normal language, whereas "from 09:00 to
>>>>> 17:00" is not. Similarly "the TV channels 1 to 4" is closed, but "from
>>>>> 1.3 to 8.6" is more likely to be half-open.
>>>>
>>>> And what about
>>>>
>>>>   string.substring(0, 10)
>>>> or
>>>>   Arrays.sort(a, 0, 10)
>>>>
>>>> or...?   These have discrete numbers too.
>>>
>>> These are indices into a list/array/string. Range defines the set of
>>> ints themselves. These is related but not entirely the same. (indices
>>> point at the gaps between things, a range of ints points at the things
>>> themselves). So, yes, I think there is a conceptual difference.
>>>
>>> I believe you need two methods. One of these three options:
>>> - rangeInclusive()
>>> - rangeExclusive()
>>>
>>> - range()
>>> - rangeExclusive()
>>>
>>> - range()
>>> - rangeInclusive()
>>>
>>> I don't currently have a strong preference between them.
>>>
>>> I don't support a boolean flag on range() as that is meaningless. An
>>> enum would be too verbose IMO.
>>> Stephen
>>>
>>
>>
>>
>>