How Swift standard types and classes were supposed to work

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

How Swift standard types and classes were supposed to work

Göktuğ Yılmaz
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Vinicius Vendramini
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

On Wednesday, November 18, 2015 at 12:13:16 PM UTC-5, Göktuğ Yılmaz wrote:
<a href="https://github.com/goktugyil/EZSwiftExtensions" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/4b46fbc8-3776-4245-9d23-9f87869b5c84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Jeremy Pereira-2
In reply to this post by Göktuğ Yılmaz
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 <[hidden email]> 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 [hidden email].
> To post to this group, send email to [hidden email].
> 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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/1C02DAD7-C97D-4049-B449-0A552719BCE8%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Göktuğ Yılmaz
In reply to this post by Vinicius Vendramini
Thanks man :)
I'll check out Objective Sugar

On Wednesday, November 18, 2015 at 9:16:59 PM UTC-8, Vinicius Vendramini wrote:
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 (<a href="https://github.com/supermarin/objectivesugar" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsupermarin%2Fobjectivesugar\46sa\75D\46sntz\0751\46usg\75AFQjCNFgpp0g4iw-AssrpP_kN6s2TAaTTg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fsupermarin%2Fobjectivesugar\46sa\75D\46sntz\0751\46usg\75AFQjCNFgpp0g4iw-AssrpP_kN6s2TAaTTg&#39;;return true;">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

On Wednesday, November 18, 2015 at 12:13:16 PM UTC-5, Göktuğ Yılmaz wrote:
<a href="https://github.com/goktugyil/EZSwiftExtensions" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/866fbf35-7bb8-40e9-87b0-5eb4a52df76c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Göktuğ Yılmaz
In reply to this post by Jeremy Pereira-2
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.

On Thursday, November 19, 2015 at 2:16:51 AM UTC-8, Jeremy Pereira wrote:
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="yEDMLbAaBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">gokt...@...> wrote:
>
> <a href="https://github.com/goktugyil/EZSwiftExtensions" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="yEDMLbAaBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">swift-languag...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="yEDMLbAaBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">swift-l...@googlegroups.com.
> To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Swift Language mailing list
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)")
}



> On 19 Nov 2015, at 16:34, Göktuğ Yılmaz <[hidden email]> wrote:
>
> 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.
>
> On Thursday, November 19, 2015 at 2:16:51 AM UTC-8, Jeremy Pereira wrote:
> 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 <[hidden email]> 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 [hidden email].
> > To post to this group, send email to [hidden email].
> > 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.
>
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/6420678A-6A68-46F2-8F9F-A46CC4A62AD7%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Göktuğ Yılmaz
Thats a good idea, thanks. I'll add it in the next update

On Friday, November 20, 2015 at 6:59:49 AM UTC-8, Jeremy Pereira wrote:
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)")
}



> On 19 Nov 2015, at 16:34, Göktuğ Yılmaz <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="wsFzm7V4BgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">gokt...@...> wrote:
>
> 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.
>
> On Thursday, November 19, 2015 at 2:16:51 AM UTC-8, Jeremy Pereira wrote:
> 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 <[hidden email]> wrote:
> >
> > <a href="https://github.com/goktugyil/EZSwiftExtensions" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fgoktugyil%2FEZSwiftExtensions\46sa\75D\46sntz\0751\46usg\75AFQjCNEq7s_3rLdpMM6ZTyjzXLwqxreprw&#39;;return true;">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 [hidden email].
> > To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/swift-language/caf4af08-1c02-4a77-80f7-c0e2461525aa%40googlegroups.com.
> > For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
>
>
> --
> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="wsFzm7V4BgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">swift-languag...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="wsFzm7V4BgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">swift-l...@googlegroups.com.
> To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/swift-language/68f07e91-fb7d-4a64-847e-eefa4fb502a5%40googlegroups.com.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/76f6255f-f739-4e09-8e00-1a5bd344e00c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Jens Alfke
In reply to this post by Vinicius Vendramini
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

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/3AEAB759-9266-4377-B3C4-649E00E1B0B6%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Kevin Ballard
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

On Fri, Nov 20, 2015, at 11:05 AM, Jens Alfke wrote:

> 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
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swift-language/3AEAB759-9266-4377-B3C4-649E00E1B0B6%40mooseyard.com.
> For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/1448072932.3536080.445881929.4D74260B%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

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

> On Nov 20, 2015, at 9:28 PM, Kevin Ballard <[hidden email]> wrote:
>
> 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
>
>> On Fri, Nov 20, 2015, at 11:05 AM, Jens Alfke wrote:
>> 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
>>
>> --
>> 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 [hidden email].
>> To post to this group, send email to [hidden email].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/swift-language/3AEAB759-9266-4377-B3C4-649E00E1B0B6%40mooseyard.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/1448072932.3536080.445881929.4D74260B%40webmail.messagingengine.com.
> For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/0E225EAC-00B2-41C3-B7C8-EA4B2B91D388%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Jens Alfke

On Nov 21, 2015, at 3:38 AM, [hidden email] 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

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/2176CC2B-F528-45D5-9868-FDD1FF40D1E8%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Daniel T.
On Nov 21, 2015, at 1:10 PM, Jens Alfke <[hidden email]> wrote:

On Nov 21, 2015, at 3:38 AM, [hidden email] 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.)

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/92E7256C-50C8-457C-B462-99A29EE0D481%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Swift Language mailing list
In reply to this post by Jens Alfke

> On 20 Nov 2015, at 19:05, Jens Alfke <[hidden email]> wrote:
>
> 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.

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


>
> —Jens
>
> --
> 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 [hidden email].
> To post to this group, send email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/3AEAB759-9266-4377-B3C4-649E00E1B0B6%40mooseyard.com.
> For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/6F6FC579-A9DD-44D3-8489-869EDD697FE0%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: How Swift standard types and classes were supposed to work

Vinicius Vendramini


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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/5c1e1302-9358-4a7e-99c6-cb55770bd098%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.