Should function arguments be reassignable or mutable?
1–10 of 28 posts
Re: Should function arguments be reassignable or mutable?
#2I feel the author isn't going far enough- make all variables immutable by default unless explicitly declared otherwise, and even then highly discouraged.
Where mutable variables are needed, I prefer to hide that logic inside a method that exists solely to do that dirty business on an abstract level, not specific to my business logic. That let's me test the 'dirty' mutable method in an isolated place and removes a whole class of mutability-related bugs from my business logic code.
Working on Java, this used to be nigh-impossible, but the Java 8 additions have truly made my life easier.
Re: Should function arguments be reassignable or mutable?
#3I think immutability of arguments should be optional by using a const keyword, like in c:
int add(const int a, const int b);Re: Should function arguments be reassignable or mutable?
#4I feel the author isn't going far enough- make all variables immutable by default unless explicitly declared otherwise, and even then highly discouraged. Where mutable variables are needed, I prefer to hide that logic inside a method that exists solely to do that dirty business on an abstract level, not specific to my business logic. That let's me test the 'dirty' mutable method in an isolated place and removes a who…
I agree up to a point.
Firstly, "Immutable by default" is recognised as a good design feature now for modern languages. But there is plenty of code in existing languages like Java, JavaScript, C, C# etc. which does not follow this rule.
Secondly, the "principle of least surprise" suggests that function arguments should work like local vars in that language. So if local vars are immutable by default, then arguments should be as well. Or if local vars can be optionally declared as immutable, then function arguments should be as well.
I can't really say what's the best for every/any language. It's not one size fit all. There are always design tradeoffs and differing schools of thought. But these days it looks a lot like "immutable by default, unless there's a good reason otherwise" is a good starting point.
Re: Should function arguments be reassignable or mutable?
#5I feel the author isn't going far enough- make all variables immutable by default unless explicitly declared otherwise, and even then highly discouraged. Where mutable variables are needed, I prefer to hide that logic inside a method that exists solely to do that dirty business on an abstract level, not specific to my business logic. That let's me test the 'dirty' mutable method in an isolated place and removes a who…
I, the author, am tending to agree now. :)
Re: Should function arguments be reassignable or mutable?
#6I feel the author isn't going far enough- make all variables immutable by default unless explicitly declared otherwise, and even then highly discouraged. Where mutable variables are needed, I prefer to hide that logic inside a method that exists solely to do that dirty business on an abstract level, not specific to my business logic. That let's me test the 'dirty' mutable method in an isolated place and removes a who…
Agreed. Erlang is another language with single assignment, i.e. every variable assignment target must have a new name. It's incredibly easy to see what calculations and conditions affect the final outcome.
Re: Should function arguments be reassignable or mutable?
#7> If we look to a language like Haskell we see that reassigning variables, in general, is frowned upon (is it even possible?)
This is perfectly valid Haskell:
main = do
let a = 7
print a
let a = 9
print a
Re: Should function arguments be reassignable or mutable?
#8Members of the E family permit `var x` instead of `x` for reassignable arguments. Having immutable names by default with a keyword to make a mutable name has worked well.
Re: Should function arguments be reassignable or mutable?
#9> If we look to a language like Haskell we see that reassigning variables, in general, is frowned upon (is it even possible?) This is perfectly valid Haskell: main = do let a = 7 print a let a = 9 print a but you'll get a warning for it: tmp.hs:4:7: warning: This binding for ‘a’ shadows the existing binding bound at tmp.hs:2:7
The warning says it right away, the first a is shadowed, not reassigned, here.
The difference is that when a is reassigned the 7 is lost, while it should be still around when shadowed. I don‘t know of a way to access the 7 in this example however.
Re: Should function arguments be reassignable or mutable?
#10I feel the author isn't going far enough- make all variables immutable by default unless explicitly declared otherwise, and even then highly discouraged. Where mutable variables are needed, I prefer to hide that logic inside a method that exists solely to do that dirty business on an abstract level, not specific to my business logic. That let's me test the 'dirty' mutable method in an isolated place and removes a who…
Historical anecdote: Algol-68 disassociated variable assignment from mutability already 50 years ago. Whenever mutability was desired, a reference to a mutable value holder was used.
Example of immutable assignment: int n = 2
Example of reference to mutable value: ref int n = (heap int := 2)
However, in order to make Algol-68 code look more similar to Algol-60, they introduced backwards-compatible shorthands, so for example the declaration int n; was actually a shorthand for ref int n = (loc int);
This shorthand magic probably contributed to why Algol-68 syntax was perceived to be difficult.
Footnote: loc and heap were the two memory allocation operators available in Algol-68.