3 ms·

How Swift standard types and classes were supposed to work

10 points by gok2 11y ago

cballard 11y ago
I think that at lot of these pollute the global scope unnecessarily or incorrectly, and many of them are semantically incorrect. It's also a massive framework that doesn't address a specific concern. It would be better packaged as a collection of μframeworks. Some specific issues: > Easily access your ViewController on top of your view stack: let topOfMyViewStack = topMostVC UIKit supports an arbitrary number of windows, so "your view stack" is not something that is definable. > Easily access your screen width & height: print(screenWidth) // 375.0 on iPhone6 print(screenHeight) // 667.0 on iPhone6 Which screen? iOS supports multiple screens - there's a reason that these things are scoped to instance properties of UIScreen. > Easily run block of code: let myBlock = { print("lol") } runThisBlock(myBlock) You can just call it directly with myBlock() - which the implementation presumably does. > Easily convert between different types: var myDouble = myInt.toDouble Double(myInt) isn't really hard, and the "easy" version is more characters. > Easily access ViewController sizes: View controllers do not have sizes - views do. I don't want to rag on the author too much, but I'd also like to add something about the tagline "How Swift standard types and classes were supposed to work". This seems needlessly offensive and incorrect - in all likelihood, Chris Lattner is smarter (or at least more educated on the subject) than you - or me! There's no need to say that he's doing his work incorrectly. Instead, a tagline like "useful extensions for the Swift Standard Library, Foundation, and UIKit" wouldn't imply that the Swift team wasn't doing their job. Save that for complaining about the inability to define a Monad protocol.
- thellimist 11y ago
  screenWidth and screenHeight is mainScreen's attributes. iOS devices have only one mainScreen. Maybe you meant the name could be changed as `mainScreenWidth`?
- gok2 11y ago
  Hello, thanks for taking the time to write feedback! I agree on your point of view on some of the matters. >Which screen? The main screen, how can I make that more clearer, I thought it was clear. >Double(myInt) isn't really hard, and the "easy" version is more characters. Correct, but it really is easier to write .toDouble() (Less keystores, more characters) I am going to update some of the stuff you said on the next update, thanks again.
sandofsky 11y ago
This library provides so many anti-patterns. "topMostVC" is going to be the source of a ton of bugs. As for aesthetics, this library will be adopted by a lot of people who don't understand Cocoa conventions. If I saw it part of a project, I'd consider it a red flag.
- gok2 11y ago
  Thanks for the feedback. I used this in 3 different app projects and topMostVC actually reduced bugs, crashes and weird looking views. If there is anything in particular I should look out for, let me know!
  - sandofsky 11y ago
    If topMostVC fixed your bugs, you probably aren't following Cocoa patterns. You're probably introducing new, subtler bugs. Honestly, I think you just need more experience before attempting a library like this.
    - gok2 11y ago
      It doesn't fix bugs. It lowers the amount of bugs to be handled in comparison to trying to present on top of a class. And maybe the example is kind of deceiving, actually it is meant for alerts and small views and stuff like that, not pushing real full screen UIViewControllers.
  - wooster 11y ago
    It's been awhile since I looked at this, but tab bar controllers (selectedViewController), navigation controllers (topViewController), and child controllers are probably going to cause your current method some difficulties.
    - gok2 11y ago
      Can you give me examples on what kind?
jcizzle 11y ago
Some of this is just poor style/naming conventions, some of it is simply implemented incorrectly and the rest of it removes necessary distinctions from important functionality.
- gok2 11y ago
  Hello, thanks for the feedback. Which ones have poor style/naming that bothers you the most? Which ones are implemented incorrectly?
sdegutis 11y ago
Actually, a default implementation of `random` on `CollectionType` isn't such a bad idea.
- gok2 11y ago
  Thats not just a not a bad idea, thats a great idea!
- masklinn 11y ago
  IME there are three random features you might want on a collection: pick a single element, pick n elements and shuffle the collection. While it can't be #2 (as that requires an elements count) the random() method could be either #1 or #3 and the naming provides no indication of which. Plus #1 and #3 (not in-place) can be expressed through #2 and likewise #1 and #2 can be expressed through #3 (not in place, especially if it's an iterator). So the naming is unhelpful and the only operation implemented is the least useful random collection operation. That's not very good. Finally you don't need to pull a whole library for that, it's a 3 lines extension.
  - sdegutis 11y ago
    > IME there are three random features you might want on a collection: pick a single element, pick n elements and shuffle the collection. While it can't be #2 (as that requires an elements count) the random() method could be either #1 or #3 and the naming provides no indication of which. I don't see the confusion. #1 would be .random(), #2 would be .random(Int), and #3 would be .shuffle() with both mutating and non-mutating versions. > So the naming is unhelpful and the only operation implemented is the least useful random collection operation. There could be all three of these methods, which you could use depending on your needs. > Finally you don't need to pull a whole library for that, it's a 3 lines extension. The purpose of a standard library is to make common things easy. At least one of these three functions are found in nearly all other languages' standard libraries I've ever used.
    - masklinn 11y ago
      > I don't see the confusion. #1 would be .random(), #2 would be .random(Int), and #3 would be .shuffle() with both mutating and non-mutating versions. All three operations are random, naming something "random" provides no indication whether it's a random indexing or a random shuffling. > There could be all three of these methods, which you could use depending on your needs. Sure, but there isn't, and the one operation which is provided is the one you can't use as basic building blocks for the other two. > The purpose of a standard library is to make common things easy. At least one of these three functions are found in nearly all other languages' standard libraries I've ever used. Your point being? I'm not saying the operation is useless, I'm saying the naming is confusing and out of 3 possible operations using that name, the least useful one was selected.
masklinn 11y ago
The string indexing extensions are just terrible. There are good reasons why Swift does not provide these things out of the box even though objective-c did: http://oleb.net/blog/2014/07/swift-strings/#character-indices-and-ranges http://oleb.net/blog/2014/07/swift-strings/#character-indice...
- gok2 11y ago
  Did you read the source code: https://github.com/goktugyil/EZSwiftExtensions/blob/master/Sources/StringExtensions.swift https://github.com/goktugyil/EZSwiftExtensions/blob/master/S... I don't see the problem?
  - masklinn 11y ago
    Did you read what I linked, and the sub-linked https://devforums.apple.com/message/1009537#1009537 https://devforums.apple.com/message/1009537#1009537 ? The way it's implemented is not relevant.

10 points by gok2 11y ago

I think that at lot of these pollute the global scope unnecessarily or incorrectly, and many of them are semantically incorrect. It's also a massive framework that doesn't address a specific concern. It would be better packaged as a collection of μframeworks. Some specific issues: > Easily access your ViewController on top of your view stack: let topOfMyViewStack = topMostVC UIKit supports an arbitrary number of windows, so "your view stack" is not something that is definable. > Easily access your screen width & height: print(screenWidth) // 375.0 on iPhone6 print(screenHeight) // 667.0 on iPhone6 Which screen? iOS supports multiple screens - there's a reason that these things are scoped to instance properties of UIScreen. > Easily run block of code: let myBlock = { print("lol") } runThisBlock(myBlock) You can just call it directly with myBlock() - which the implementation presumably does. > Easily convert between different types: var myDouble = myInt.toDouble Double(myInt) isn't really hard, and the "easy" version is more characters. > Easily access ViewController sizes: View controllers do not have sizes - views do. I don't want to rag on the author too much, but I'd also like to add something about the tagline "How Swift standard types and classes were supposed to work". This seems needlessly offensive and incorrect - in all likelihood, Chris Lattner is smarter (or at least more educated on the subject) than you - or me! There's no need to say that he's doing his work incorrectly. Instead, a tagline like "useful extensions for the Swift Standard Library, Foundation, and UIKit" wouldn't imply that the Swift team wasn't doing their job. Save that for complaining about the inability to define a Monad protocol.

thellimist 11y ago
screenWidth and screenHeight is mainScreen's attributes. iOS devices have only one mainScreen. Maybe you meant the name could be changed as `mainScreenWidth`?
gok2 11y ago
Hello, thanks for taking the time to write feedback! I agree on your point of view on some of the matters. >Which screen? The main screen, how can I make that more clearer, I thought it was clear. >Double(myInt) isn't really hard, and the "easy" version is more characters. Correct, but it really is easier to write .toDouble() (Less keystores, more characters) I am going to update some of the stuff you said on the next update, thanks again.

sandofsky 11y ago

This library provides so many anti-patterns. "topMostVC" is going to be the source of a ton of bugs. As for aesthetics, this library will be adopted by a lot of people who don't understand Cocoa conventions. If I saw it part of a project, I'd consider it a red flag.

gok2 11y ago
Thanks for the feedback. I used this in 3 different app projects and topMostVC actually reduced bugs, crashes and weird looking views. If there is anything in particular I should look out for, let me know!
- sandofsky 11y ago
  If topMostVC fixed your bugs, you probably aren't following Cocoa patterns. You're probably introducing new, subtler bugs. Honestly, I think you just need more experience before attempting a library like this.
  - gok2 11y ago
    It doesn't fix bugs. It lowers the amount of bugs to be handled in comparison to trying to present on top of a class. And maybe the example is kind of deceiving, actually it is meant for alerts and small views and stuff like that, not pushing real full screen UIViewControllers.
- wooster 11y ago
  It's been awhile since I looked at this, but tab bar controllers (selectedViewController), navigation controllers (topViewController), and child controllers are probably going to cause your current method some difficulties.
  - gok2 11y ago
    Can you give me examples on what kind?

jcizzle 11y ago

Some of this is just poor style/naming conventions, some of it is simply implemented incorrectly and the rest of it removes necessary distinctions from important functionality.

gok2 11y ago
Hello, thanks for the feedback. Which ones have poor style/naming that bothers you the most? Which ones are implemented incorrectly?

sdegutis 11y ago

Actually, a default implementation of `random` on `CollectionType` isn't such a bad idea.

gok2 11y ago
Thats not just a not a bad idea, thats a great idea!
masklinn 11y ago
IME there are three random features you might want on a collection: pick a single element, pick n elements and shuffle the collection. While it can't be #2 (as that requires an elements count) the random() method could be either #1 or #3 and the naming provides no indication of which. Plus #1 and #3 (not in-place) can be expressed through #2 and likewise #1 and #2 can be expressed through #3 (not in place, especially if it's an iterator). So the naming is unhelpful and the only operation implemented is the least useful random collection operation. That's not very good. Finally you don't need to pull a whole library for that, it's a 3 lines extension.
- sdegutis 11y ago
  > IME there are three random features you might want on a collection: pick a single element, pick n elements and shuffle the collection. While it can't be #2 (as that requires an elements count) the random() method could be either #1 or #3 and the naming provides no indication of which. I don't see the confusion. #1 would be .random(), #2 would be .random(Int), and #3 would be .shuffle() with both mutating and non-mutating versions. > So the naming is unhelpful and the only operation implemented is the least useful random collection operation. There could be all three of these methods, which you could use depending on your needs. > Finally you don't need to pull a whole library for that, it's a 3 lines extension. The purpose of a standard library is to make common things easy. At least one of these three functions are found in nearly all other languages' standard libraries I've ever used.
  - masklinn 11y ago
    > I don't see the confusion. #1 would be .random(), #2 would be .random(Int), and #3 would be .shuffle() with both mutating and non-mutating versions. All three operations are random, naming something "random" provides no indication whether it's a random indexing or a random shuffling. > There could be all three of these methods, which you could use depending on your needs. Sure, but there isn't, and the one operation which is provided is the one you can't use as basic building blocks for the other two. > The purpose of a standard library is to make common things easy. At least one of these three functions are found in nearly all other languages' standard libraries I've ever used. Your point being? I'm not saying the operation is useless, I'm saying the naming is confusing and out of 3 possible operations using that name, the least useful one was selected.

masklinn 11y ago

The string indexing extensions are just terrible. There are good reasons why Swift does not provide these things out of the box even though objective-c did: http://oleb.net/blog/2014/07/swift-strings/#character-indices-and-ranges http://oleb.net/blog/2014/07/swift-strings/#character-indice...

gok2 11y ago
Did you read the source code: https://github.com/goktugyil/EZSwiftExtensions/blob/master/Sources/StringExtensions.swift https://github.com/goktugyil/EZSwiftExtensions/blob/master/S... I don't see the problem?
- masklinn 11y ago
  Did you read what I linked, and the sub-linked https://devforums.apple.com/message/1009537#1009537 https://devforums.apple.com/message/1009537#1009537 ? The way it's implemented is not relevant.