
How Swift standard types and classes were supposed to work - gok2
https://github.com/goktugyil/EZSwiftExtensions
======
cballard
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.

~~~
gok2
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
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
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!

~~~
wooster
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
Can you give me examples on what kind?

~~~
wooster
A navigation controller presenting a tab bar controller presenting a
navigation controller with a child controller presenting a tab bar controller…
on an iPad. Or any set of permutations of those.

~~~
gok2
Yeah that would actually break it.

------
jcizzle
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
Hello, thanks for the feedback. Which ones have poor style/naming that bothers
you the most? Which ones are implemented incorrectly?

------
masklinn
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-
indice...](http://oleb.net/blog/2014/07/swift-strings/#character-indices-and-
ranges)

~~~
gok2
Did you read the source code:
[https://github.com/goktugyil/EZSwiftExtensions/blob/master/S...](https://github.com/goktugyil/EZSwiftExtensions/blob/master/Sources/StringExtensions.swift)
I don't see the problem?

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

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

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

