> I'd have to see the code but it sounds like bad design.
I think that dev called that "enum case with parameters" or something similar. Don't really remember at this point.
> _why on earth_ would you ever want to be able to override that func's params and feed it something else?
No, I meant overwriting function arguments within the function itself to avoid rewriting the code below that point. I do sometimes do that in Java and I find it a sensible thing to do. For example
public String doSomethingWithTwoStrings(String a, String b){
if(some condition){
a=something else;
}
// do something with (possibly overwritten above) a and b
return result;
}
I'm used to treating function parameters as pre-populated local variables. Swift compiler gets in the way and doesn't let me do that because immutability. Comparing with Java, it's as if everything is `final` by default.
> enum case with parameters
Ah, this is a language feature of enums in Swift. Swift enums allow you to keep associated values with a specific case and you need to unpack them with a `let` when dealing with that value.
E.g.
enum Animal {
case lion
case tiger
case bear
case ohMy(Int)
}
The case `ohMy(Int)` means that it has an associated value so when you want to get at it from a variable, say:
var a:Animal
switch a {
case .ohMy(let value):
// do something with `value`
...
}
Ah, I see what you mean. Thanks for the explanation.
This is just my opinion but doing that seems to be very dangerous. You're probably fine for small functions with single-developers, but once you get complex and have multiple people working on the code it seems easy for one dev to confuse another.
If you insist on that pattern (lets call it the local variable method) you can define vars such as
var localA = a
var localB = b
at the top of the function and work on it there. Personally I prefer function arguments to be immutable, so that any time you call them you know what you're working on is what the function was given. Forcing you to declare a local var makes the code much more explicit and easy for another human to reason about what you're doing, whereas they could very easily miss an "a=something else".
I think you should RTFM before jumping in and trying to code by guessing the language semantics. All of these things you dislike are easily achieved by a small change in keyword or function signature.
I think that dev called that "enum case with parameters" or something similar. Don't really remember at this point.
> _why on earth_ would you ever want to be able to override that func's params and feed it something else?
No, I meant overwriting function arguments within the function itself to avoid rewriting the code below that point. I do sometimes do that in Java and I find it a sensible thing to do. For example
I'm used to treating function parameters as pre-populated local variables. Swift compiler gets in the way and doesn't let me do that because immutability. Comparing with Java, it's as if everything is `final` by default.