Comment by grishka | Hacker News Reader

Comment by grishka | Hacker News Reader

Parent Full thread

Coming from Java and C++, I once wanted to fix a bug in a macOS app written in Swift that used my C++ library. It was a rather frustrating experience because none of my existing knowledge worked. 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. It turns out (had to ask the developer who wrote this) I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use. 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.

And yes, versions, as you said. I don't like moving targets. I enjoy stability. Java changes, but it at least does so carefully and doesn't drop features (but does sometimes drop obscure parts of the standard library). You can usually compile and run Java 6 code unchanged with JDK 17 just fine.

I like it when there's a clear line between the language itself and its standard library. Swift doesn't have one, neither does Kotlin.

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

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

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.

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

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

There's no clear line between language and standard library in C++ or in Java.

Reply on news.ycombinator.com