How Swift standard types and classes were supposed to work

60 views
Skip to first unread message

Göktuğ Yılmaz

unread,
Nov 18, 2015, 12:13:16 PM11/18/15
to Swift Language
https://github.com/goktugyil/EZSwiftExtensions

Any feedback is welcome. This contains a series of extensions to make swift and uikit better.

Vinicius Vendramini

unread,
Nov 19, 2015, 12:16:59 AM11/19/15
to Swift Language
Dude, that's pretty damn cool! I love the additions to the base classes like Arrays and Strings (and the repeat methods, in particular) =)

I used to use Objective Sugar (https://github.com/supermarin/objectivesugar) a lot in Objective-C, and you had some great ideas for Swift. I would be all over this if I still worked with app development. The UIView additions would have been particularly helpful back then...

Keep it up =D

Jeremy Pereira

unread,
Nov 19, 2015, 5:16:51 AM11/19/15
to Göktuğ Yılmaz, Swift Language
Some interesting ideas there.

But I have to ask, what is the point of the “runThisBlock” function?

> On 18 Nov 2015, at 16:56, Göktuğ Yılmaz <gokt...@gmail.com> wrote:
>
> https://github.com/goktugyil/EZSwiftExtensions
>
> Any feedback is welcome. This contains a series of extensions to make swift and uikit better.
>
> --
> You received this message because you are subscribed to the Google Groups "Swift Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to swift-languag...@googlegroups.com.
> To post to this group, send email to swift-l...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Göktuğ Yılmaz

unread,
Nov 19, 2015, 11:31:33 AM11/19/15
to Swift Language
Thanks man :)
I'll check out Objective Sugar

Göktuğ Yılmaz

unread,
Nov 19, 2015, 11:34:49 AM11/19/15
to Swift Language, gokt...@gmail.com
It makes the code more readable and autocomplete friendly than the standard running of block ()
Though it is pretty much useless and only a convenience method.

Jeremy Pereira

unread,
Nov 20, 2015, 9:59:49 AM11/20/15
to Göktuğ Yılmaz, Swift Language
I’m not sure I agree about readability, but each to his own.

One thing you should do (and this applies to all of your functions that take a block parameter and then runs it) is use rethrows i.e.


public func runThisBlock(block: () throws -> ()) rethrows
{
try block()
}

That way, people can pass a block that throws an exception if they want.

e.g.

let block = { print("Hi") } // Doesn’t throw

runThisBlock(block) // prints Hi

enum MyError: ErrorType
{
case Generic
}
let throwBlock = { throw MyError.Generic } // does throw

// The following prints Generic
do
{
try runThisBlock(throwBlock)
}
catch
{
print("\(error)")
> To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com.

Göktuğ Yılmaz

unread,
Nov 20, 2015, 1:14:02 PM11/20/15
to Swift Language, gokt...@gmail.com
Thats a good idea, thanks. I'll add it in the next update

Jens Alfke

unread,
Nov 20, 2015, 2:06:04 PM11/20/15
to Vinicius Vendramini, Swift Language
Looks like a lot of useful stuff there, but I dislike having a bunch of functions in the top-level namespace, especially ones that are only useful for GUI-level iOS code. Swift doesn’t have syntax for adding a namespace the way C++ does, but you could get the same effect by making them class methods, like

public class IOSApp {
public class var version: String { … }
}

Then you call them as “IOSApp.version”, etc.

—Jens

Kevin Ballard

unread,
Nov 20, 2015, 9:28:57 PM11/20/15
to swift-l...@googlegroups.com
I'd recommend using structs, not classes. No real practical difference,
except it avoids creating runtime metadata for the type (classes have
obj-c metadata).

public struct Namespace {
public static var foo: String { ... }
}

-Kevin
> --
> You received this message because you are subscribed to the Google Groups
> "Swift Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to swift-languag...@googlegroups.com.
> To post to this group, send email to swift-l...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swift-language/3AEAB759-9266-4377-B3C4-649E00E1B0B6%40mooseyard.com.

danie...@gmail.com

unread,
Nov 21, 2015, 6:38:21 AM11/21/15
to swift-l...@googlegroups.com
I strongly dislike the idea of using classes, or structs, as namespaces. Swift has a namespace system, the module, and further wrapping is unnecessary.

Sent from my iPad
> To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/1448072932.3536080.445881929.4D74260B%40webmail.messagingengine.com.

Jens Alfke

unread,
Nov 21, 2015, 1:10:21 PM11/21/15
to Daniel T., swift-l...@googlegroups.com

On Nov 21, 2015, at 3:38 AM, danie...@gmail.com wrote:

I strongly dislike the idea of using classes, or structs, as namespaces. Swift has a namespace system, the module, and further wrapping is unnecessary.

Modules in Swift are pretty heavyweight/awkward, since they correspond to targets at build time and frameworks at runtime. This seems to encourage libraries to be one large module, often filled with unrelated things (like the one in question.) In that case I think it’s beneficial to subdivide the namespace somehow.

Also, I don’t think it’s good design for a property like “screenWidth” or “appVersion” to be a standalone top-level value. These are intrinsically properties of (singleton) objects like The Screen or The Application, so I’d rather see them as Screen.width or App.version.

(Note that C++ has namespaces, but it’s common for global properties to be exposed as static functions of classes, where that nesting makes sense.)

—Jens

Daniel Tartaglia

unread,
Nov 21, 2015, 2:01:41 PM11/21/15
to swift-l...@googlegroups.com
On Nov 21, 2015, at 1:10 PM, Jens Alfke <je...@mooseyard.com> wrote:

On Nov 21, 2015, at 3:38 AM, danie...@gmail.com wrote:

I strongly dislike the idea of using classes, or structs, as namespaces. Swift has a namespace system, the module, and further wrapping is unnecessary.

Modules in Swift are pretty heavyweight/awkward, since they correspond to targets at build time and frameworks at runtime. This seems to encourage libraries to be one large module, often filled with unrelated things (like the one in question.) In that case I think it’s beneficial to subdivide the namespace somehow.

Well, I think we can agree that putting a grab bag of unrelated code in a single module is a bad design choice, but I don’t see how turning that module into a grab bag of unrelated structs as namespaces which contain the same unrelated code would help the situation. In other words, I feel that the apparent need for struct as namespaces in this module exposes a fundamental problem with the module, and adding the structs as namespaces is nothing more than a failed attempt at a bandaid.

Also, I don’t think it’s good design for a property like “screenWidth” or “appVersion” to be a standalone top-level value. These are intrinsically properties of (singleton) objects like The Screen or The Application, so I’d rather see them as Screen.width or App.version.

Making these calls proper members of a class (not static members, but object level functions,) is something I think we could agree on maybe? 

The only real difference between “appVersion()” and “TheApplication.appVersion()” is the length of the name. In either case, they are still global functions. There is nothing more modular about the later compared to the former. IMHO
 
(I may be sounding too argumentative in the above, but as I said, I strongly dislike the notion.)

Jeremy Pereira

unread,
Nov 23, 2015, 5:07:32 AM11/23/15
to Jens Alfke, Vinicius Vendramini, Swift Language
I’m not a fan of classes with nothing but static/class methods. Why not add them as an extension to UIApplication?

Vinicius Vendramini

unread,
Nov 23, 2015, 10:12:03 AM11/23/15
to Swift Language, je...@mooseyard.com, viniv...@gmail.com


I’m not a fan of classes with nothing but static/class  methods. Why not add them as an extension to UIApplication?



+1!

Best idea so far, imo.
Reply all
Reply to author
Forward
0 new messages