commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [MATH] Interest in large patches for small cleanup / performance changes?
Date Sun, 03 Nov 2013 22:57:21 GMT
On Sun, 03 Nov 2013 21:03:02 +0100, Luc Maisonobe wrote:
> Le 03/11/2013 20:17, Ted Dunning a écrit :
>> On Sun, Nov 3, 2013 at 10:56 AM, Luc Maisonobe <> 
>> wrote:
>>>> I had proposed that error messages be incrementally built from 
>>>> simple
>>>> "base" patterns, to be assembled either at the point where the 
>>>> exception
>>>> is going to be thrown or inside specific exceptions[2] (or a 
>>>> combination
>>>> of both).
>>> It often doesn't work. Sentences constructions are completely 
>>> different
>>> in different languages, and it is impossible to simply buid up from
>>> elementary components that are individually translated and 
>>> assembled
>>> later. See all the documentation about the ancient gettext for 
>>> example.

I think that a message good enough to convey the cause of the failure 
in many cases be built from such blocks. I concede that it may not be
perfectly formulated in a natural language, but even if it where, the 
message are _rarely_ if ever clear, an one needs to refer to the 
in order to understand what caused the exception. There the error 
is hopefully (as it should) explained in a nice and clear sentences.

There are drawbacks in having these hundreds of messages patterns.

>> Modern printf implementations deal with this by numbered arguments.  
>> This
>> is not a problem any more.
> Which means you have a complete message with a sentence that simply 
> has
> placeholders for variables parts. What I understand about Gilles
> proposal is to go further in the way of small blocks like 
> CONSTRAINT, EVALUATION, INDEX, NORM, and build up from there. Is it 
> what
> was initially meant?

Not sure I understand what you wrote. But, yes; where a juxtaposition 
the blocks is good enough, we could readily use it. That will reduce 
the list
quite substantially. When we get rid of all the similar patterns, it 
will be
more acceptable to keep a few longer patters where really necessary.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message