Re: Design philosophy - why use a VAR for a single return value?

[Tony Wallace]

I totally support this move.  As a functional programmer this makes
sense.  If a bit set operation updates variable for example, this can
be achieved with an assignment to the return value of the function.



On Fri, 2024-03-22 at 18:51 -0400, Alice Osako wrote:
>  I am changing the API for CardBitOps to eliminate all VAR parameters
> for any case where only a single value is returned. 
>  
>  I am baffled as to why the original design used them in the first
> place, and dealing with that bad design decision was driving me up
> the wall. 
>  
>  It is a basic principle of software design to minimize side effects.
> VAR parameters are by definition side effects. While they are
> justifiable in many instances, as a rule you should never modify a
> parameter when a return value is feasible. I would expect everyone to
> understand this. 
>  
>  I didn't want to do this, as I intended to maintain compatibility
> with the existing M2 R10 API, but after the nth time having to create
> a temporary variable solely to keep the procedures from altering a
> critical argument which needed to be preserved for later use, I
> simply felt that this design wart needed to be fixed.
>  
>  Benjamin, I don't want to step on your toes here, but I do see this
> as something that can and should be changed. Was there a reason why
> they were defined this way in the first place? Am I missing
> something? Or was this a legacy design that needed to be maintained
> for whatever reason?
>  
>  I apologize for the harsh tone of this post, but I really felt this
> needed to be addressed.
>