[rfc][icedtea-web] Move Translation Responsibility from JNLPRuntime to Translator

[Andrew Azores]

On 09/15/2014 10:27 AM, Jie Kang wrote:
>>>
>>> I am not sure if I understood correctly but for this R(String message) do
>>> you mean something like:
>>>     return R(message, new Object[0])
>>>
>>> I prefer the other way since it's more efficient and makes more sense to me
>>> hahah. Though I understand what you mean by being more natural. It's just
>>> on closer inspection it seems really weird to make this call when you can
>>> just use getInstance().getMessage(message);
>>>
>>> Is it okay if I keep it original?
>>
>> Sure, this definitely is not a blocker on push. I think "efficiency"
>> here is a pretty weak reason though ;) it's just one extra method call,
>> not very heavy. The other benefit is that if down the line somebody
>> wants to add some extra validation or something, for example, then it
>> only needs to be added in one of the methods, rather than both overloads.
>>
>> It's also a little bit confusing looking because since R(String,
>> Object...) is varargs, it's actually valid to call it simply as, for
>> example, R("TEST"). In this case, your varargs array just ends up being
>> the empty array. So what you've done by defining both methods is
>> essentially add a constraint for the varargs that it has to be of at
>> least size 1, then branching into different calls to getMessage, one of
>> which is actually defined in terms of the other in failure cases
>> anyway... the call web is just a bit tangled is what I'm trying to say.
>> But it's fine as-is regardless.
>
> Hello,
>
> Just wanted to say thanks for this explanation! I decided to go with what you suggested instead. Since the varargs case accepts 0 args, we can technically remove the function R(String message) and just have R(String message, Object ... params), no? Do you think it'd be good to remove R(String message) in this patch?
>
>
> Regards,
>

Sure, post the patch at will :)

Thanks,
-- 
Andrew Azores