Hello Robert,
>> However, for obvious reasons the committer opinion prevails:-)
>
> You're welcome to solicit other opinions. I'm not unwilling to give
> way if there's a chorus of support for the way you've done it.
Hmmm. I do not expect much chorus on such a minor subject:-)
> But to me it sounds like you're saying that it doesn't really matter
> whether the system is scalable and maintainable because we only have 5
> functions right now, which is a design philosophy with which I just
> don't agree.
The design does not aim at scalability but at simplicity, otherwise I
would have done things quite differently: with many functions the "switch"
based selection does not scale anyway.
Anyway, attached are two patches, one for each approach.
The array (second patch) is not too bad if one agrees with a maximum
number of arguments, and also as I did not change the list structure
coming from the parser, so it does not need to manage the number of
arguments in the function structure. The code for min/max is also simpler
when dealing with an array instead of a linked list. I do not like much
array references in the code, so I tried to avoid them by using lval/rval
scalars for operator operands.
Please choose the one you prefer, and I'll adapt the remaining stuff to
your choice.
--
Fabien.
