Re: [icu-design] Additional method for PluralRules

[Mark D. ☕ <ma...@ma...>]

Whoops, missent. Now adding comments below!

Mark

*— Il meglio è l’inimico del bene —*


On Mon, Jan 31, 2011 at 15:49, Mark Davis ☕ <ma...@ma...> wrote:

> Ticket: http://bugs.icu-project.org/trac/ticket/8317
> API Reviewer: Markus
> Feedback deadline: 2011-02-07
>
> Other comments below.
>
> Mark
>
> *— Il meglio è l’inimico del bene —*
>
>
> On Tue, Aug 17, 2010 at 16:25, Markus Scherer <mar...@gm...>wrote:
>
>> On Tue, Aug 17, 2010 at 3:23 PM, Mark Davis ☕ <ma...@ma...> wrote:
>>
>>> I'm proposing the following single-method addition:
>>>
>>
>> Please add a ticket, designated API reviewer, and feedback deadline. (
>> http://site.icu-project.org/processes/proposal-template)
>>
>> Issues:
>>>
>>>    - if we removed the max parameter, and just hard-coded the max (at
>>>    say 10), then we could compute the list statically for each distinct
>>>    rulelist.
>>>
>>> I prefer having the max parameter. I think it will be useful for demos
>> and validation to use a max of 2 or 3. And the max helps with the "dumb"
>> implementation.
>>
>
It would need to be well-understood that the number of elements returned may
be less than the maximum (eg, might be 1). That is, if I call it with a max
of 10, it could return 1 value, and I don't know whether or not there are
any more than 1 value possible. (Ideally, however, you'd get more than one
sample any time the plural category contains more than one, just for
clarity.)

So I think it is actually more understandable just to return some values,
without the user being able to specify how many. We could add a max later if
we really found it useful.


>
>>>    - in C++, we'd deposit the results into an array, with the normal ICU
>>>    idiom.
>>>
>>> Not quite the normal ICU idiom: If there are more than max sample values,
>> we would not try to tell you how many there are, and we would not set a
>> U_BUFFER_OVERFLOW_ERROR.
>>
>
agreed.


>
>> And would it not be more efficient (and just as easy to use) to pass a
>> fill-in array in Java as well? Then you would not allocate new storage each
>> time you call getSamples().
>>
>
this API should slant towards ease-of-use; efficiency is (very) secondary.


>
>> int getSamples(String keyword, double[] samples, int max)
>>
>>>
>>>    - theoretically, one of the keywords could only apply above 256, or
>>>    only be solitary under that.
>>>
>>> I think we should just cover that with a unit test for now, testing up to
>> a higher number in the test code and seeing if we get the same results with
>> max=2 as with getSamples().
>>
>> markus
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> icu-design mailing list
>> icu...@li...
>> To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design
>>
>
>