Michael Chermside wrote:
#- Imagine the following senario. I write some code which uses #- Decimal, and which sets the context to get the desired rounding #- behavior. Somewhere in my code I call a routine written by #- somebody else... perhaps some library code... which also does #- some calculations using Decimal.
This subject already has been discussed in c.l.p:
Emile van Sebille:
...from which I infer that Context exists in part to limit/round calculated results. Even if it were possible for me, as a user of Decimal, to set Context appropriately to achieve these ends, what if I use a library that also changes Context? The integrity of my calculations may be impacted.
That's correct. There needs to be a social convention that libraries intended for use by other people *CANNOT* muck with Context, and if they do so for their own internal calculations, they must save and restore Context. You can probably find additional information about this in Cowlishaw.
Emile van Sebille:
Enter the context stack.
Well, sure. And it won't be hard to add given that Decimal will already need to track thread-specific Context. But modules changing Context will still need to explicitly push and pop Context because usually you will just want to replace the current Context.
They have another choice, because Guido had a brilliant idea: the arithmetic operations in Eric's implementation are methods *of* a context object (because Guido suggested that). So a maximally robust library doesn't *have* to change the thread context at all: it can create whatever private context object(s) it needs, and spell arithmetic as explicit method calls on its private context object(s), so that the default thread context object is neither consulted nor modified. This is very robust, and in small doses is quite bearable.
I don't have any problem to implement a context stack. But I think that it's no clear to be useful, so I think it's better to go for the sure staff, and when Decimal gets heavy use, if everybody agrees to add a context stack, we'll go for it.
What do you think?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA
La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley.
Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo.
Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada.
Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje.
... I don't have any problem to implement a context stack. But I think that it's no clear to be useful, so I think it's better to go for the sure staff, and when Decimal gets heavy use, if everybody agrees to add a context stack, we'll go for it. What do you think? .
YAGNI (You Ain't Gonna Need It). Most apps will never change the context. Most of the rest will set it once at program start (typically just to increase precision), and never change it again. The same is true of the elaborate FPU control registers in the Pentium HW most of the world uses today, and the "numeric context" here is just a small generalization of that.
This isn't to say that numeric context isn't useful (or the elaborate FPU control registers): it's extremely useful, but generally only to a handful of numeric experts writing library utilities with severe "works in all possible endcases" requirements. They'll have the responsibility to document the effects their code has on context (when does it signal inexact? overflow? etc), and because they will change context visible to the caller in the documented ways, they've got no use for a stack (they'll generally need to restore *parts* of the context to entry conditions, but change other parts in defined ways -- same as, e.g., the builtin addition function).