3 ms·

> Header files. Wait, what?!? Yes, I prefer having header files to not having header files. > Verbosity. Wait, what?!? Yes, I prefer the verbosity of Objecti

> Header files. Wait, what?!? Yes, I prefer having header files to not having header files. > Verbosity. Wait, what?!? Yes, I prefer the verbosity of Objective-C method names. I agree with a lot of what the author wrote, but this… this I cannot stand behind.

dinkblam 3y ago
why would a verbose name (like stringByReplacingOccurrencesOfString:withString:) not be better than something short but completely meaningless and obscure like /strtol/? we have autocompletion these days...
- happytoexplain 3y ago
  Why are you making such a large jump? The Swift version is 'replacingOccurrences(of:with:)', where all three types are strings. Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete).
  - dinkblam 3y ago
    > Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete). can you elaborate? the verbosity is good while reading, because you know what it does even if you don't know the API in your sleep. how could there be a verbosity cost while reading?
  - catoc 3y ago
    Verbosity is in-place documentation. I personally like it. I have personal projects where, as the original creator and maintainer of the codebase, I should easily be able to understand what happens. But time and time again I find my current self being grateful to my former self for 'documenting' methods calls and variables by being verbose. [edit: removed typo]
- tambourine_man 3y ago
  I like terseness while reading as well. I get angry and bored with verbosity.
Pulcinella 3y ago
Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose as you want. So I am not really sure what the complaint actually is. Not having header files has literally never been a problem for me. Xcode can auto generate a sort of pseudo-header definition file if you are pulling in someone else’s frameworks. And day to day app work mostly consist of writing code for the app, not writing a library or framework for others to use. You still have public and private methods. I guess not having separate header files makes it slightly easier to expose things you should probably keep private, but that really is just a thing that is solved by “just don’t do that.” Finally, a lot of times people will just have a private extension to a class that contains all the private methods anyway. So you basically just have everything combined in the same .swift file, where you have a “logical” header rather than a separate header file.

dinkblam 3y ago

why would a verbose name (like stringByReplacingOccurrencesOfString:withString:) not be better than something short but completely meaningless and obscure like /strtol/? we have autocompletion these days...

happytoexplain 3y ago
Why are you making such a large jump? The Swift version is 'replacingOccurrences(of:with:)', where all three types are strings. Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete).
- dinkblam 3y ago
  > Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete). can you elaborate? the verbosity is good while reading, because you know what it does even if you don't know the API in your sleep. how could there be a verbosity cost while reading?
- catoc 3y ago
  Verbosity is in-place documentation. I personally like it. I have personal projects where, as the original creator and maintainer of the codebase, I should easily be able to understand what happens. But time and time again I find my current self being grateful to my former self for 'documenting' methods calls and variables by being verbose. [edit: removed typo]
tambourine_man 3y ago
I like terseness while reading as well. I get angry and bored with verbosity.

Pulcinella 3y ago

Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose as you want. So I am not really sure what the complaint actually is. Not having header files has literally never been a problem for me. Xcode can auto generate a sort of pseudo-header definition file if you are pulling in someone else’s frameworks. And day to day app work mostly consist of writing code for the app, not writing a library or framework for others to use. You still have public and private methods. I guess not having separate header files makes it slightly easier to expose things you should probably keep private, but that really is just a thing that is solved by “just don’t do that.” Finally, a lot of times people will just have a private extension to a class that contains all the private methods anyway. So you basically just have everything combined in the same .swift file, where you have a “logical” header rather than a separate header file.