4 ms·

>It was a rather frustrating experience because none of my existing knowledge worked. Well, it is a new language >I could see the field I needed in the object

by zionic 5y ago

>It was a rather frustrating experience because none of my existing knowledge worked. Well, it is a new language >I could see the field I needed in the object in the debugger, but for the life of me couldn't figure out how to get it. I would need more context to help you out here. You had SomeObject with a child SomeChild and couldn't do let a= SomeObject.SomeChild ? Perhaps I'm misunderstanding. >I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use. Sounds like this is importing from some file or something, and whoever wrote the code below you just made everything optional and chucked all the responsibility for that up the chain. I'd have to see the code but it sounds like bad design. >Also, immutable everything by default. You can't overwrite function arguments within the function itself, like you could in Java and C++. And unwrap, unwrap, unwrap, unwrap, unwrap everything. That's a feature not a bug. Maybe I'm misunderstanding you, but if you have func twoStrings(a: String, b: String) -> String, _why on earth_ would you ever want to be able to override that func's params and feed it something else? a/b would be a completely unexpected type and blow up/fail to compile. If you're routinely needing to do this, you haven't embraced static typing I think. Swift Generics are a potential option.

grishka 5y ago
> 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.
- hawflakes 5y ago
  > 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` ... }
- fingerlocks 5y ago
  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.
- zionic 5y ago
  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".

by zionic 5y ago

grishka 5y ago

> 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.

hawflakes 5y ago
> 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` ... }
fingerlocks 5y ago
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.
zionic 5y ago
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".