Discussion: Singletons? about swift-style-guide HOT 9 CLOSED

I was also already wondering about that🍅 since we don't have any other
guidance I though best way is to go with gcd ...

On Monday, June 16, 2014, Pietro Rea [email protected] wrote:

What should be the appropriate syntax for declaring singletons in Swift?
Should we still use dispatch_once or does a global constant variable
suffice? Both official books on Swift don't even include the word
"singleton", so we're not getting much guidance from Apple here.

—
Reply to this email directly or view it on GitHub
#20.

from swift-style-guide.

I have a feeling it is too early to make a call on this one. Right now I think GCD is the only option.

At the moment Swift doesn't have any indication of atomicity. However, when this arrives i am assuming a singleton can simply be implemented as an atomic static @lazy property.

from swift-style-guide.

Like this:

class MySingleton {
    class func sharedInstance() -> MySingleton {
        return mySingletonGlobal
    }
    ....
}

let mySingletonGlobal = MySingleton()

The global mySingletonGlobal is initialized lazily and atomically (using dispatch_once behind the scenes).

Another approach is:

class MySingleton {
  class var sharedInstance: MySingleton {
    struct Singleton {
      static let instance = MySingleton()
    }
    return Singleton.instance
  }
  ....
}

This does not use a global constant but wraps the initialization into a static member of a nested struct. This also gets initialized lazily and atomically.

There is no need to use GCD directly.

from swift-style-guide.

Ah, I see. There has been some very useful discussion, including those two approaches, on Stackoverflow:

http://stackoverflow.com/questions/24024549/dispatch-once-singleton-model-in-swift

from swift-style-guide.

See also here: https://devforums.apple.com/thread/229436

from swift-style-guide.

I'm still having trouble accepting all these globals. Your first example is nice, but the function is unnecessary because the singleton is already global.

As such, I prefer the second approach, even though it looks uglier/more complex. At least with the second, you need to go through the class to get it, which "feels" more right to me.

That said, I'm fine with whichever approach is more popular.

Sent from my iPhone

On Jun 16, 2014, at 5:51 AM, Matthijs Hollemans [email protected] wrote:

Like this:

class MySingleton {
class func sharedInstance() -> MySingleton {
return mySingletonGlobal
}
....
}

let mySingletonGlobal = MySingleton()
The global mySingletonGlobal is initialized lazily and atomically (using dispatch_once behind the scenes).

Another approach is:

class MySingleton {
class var sharedInstance: MySingleton {
struct Singleton {
static let instance = MySingleton()
}
return Singleton.instance
}
....
}
This does not use a global constant but wraps the initialization into a static member of a nested struct. This also gets initialized lazily and atomically.

There is no need to use GCD directly.

—
Reply to this email directly or view it on GitHub.

from swift-style-guide.

The reason the first example has a sharedInstance() function is that you want people to access the singleton through that. If they really want to, they can also go through the global constant. You can't really prevent this, but you can discourage it through giving the global an ugly name and by documenting that callers should use sharedInstance().

A singleton is an embodiment of global state anyway. If you don't like globals, you shouldn't use singletons. ;-)

I wonder what is nicer, though: a sharedInstance() function or a sharedInstance variable:

class MySingleton {
  class var sharedInstance: MySingleton {
    return mySingletonGlobal
  }
  // vs
  class func sharedInstance() -> MySingleton {
    return mySingletonGlobal
  }
  ...

from swift-style-guide.

I realize that. My complaint about the global is the fact that it is a name completely unattached to any type. It's just out there in the app's namespace, rather than contained within the type's namespace. I like at least forcing the caller to go through the type rather than "encouraging" it.

In your two examples there, I would prefer the property. At least you can call it using MySingleton.sharedInstance instead of MySingleton.sharedInstance(), right? No technical reason for that preference, it just feels nicer to me.

BTW, I will prefer this solution over the nested struct thing you showed before once we are allowed private variables, because then you could actually make the singleton variable private rather than this kludgy stuff of having one property return another variable which is you can access freely without that property.

--------- Original Message --------- Subject: Re: [swift-style-guide] Discussion: Singletons? (#20)
From: "Matthijs Hollemans" [email protected]
Date: 6/16/14 10:33 am
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

The reason the first example has a sharedInstance() function is that you want people to access the singleton through that. If they really want to, they can also go through the global constant. You can't really prevent this, but you can discourage it through giving the global an ugly name and by documenting that callers should use sharedInstance().
A singleton is an embodiment of global state anyway. If you don't like globals, you shouldn't use singletons. ;-)
I wonder what is nicer, though: a sharedInstance() function or a sharedInstance variable:
class MySingleton { class var sharedInstance: MySingleton { return mySingletonGlobal } // vs class func sharedInstance() -> MySingleton { return mySingletonGlobal } ... -
Reply to this email directly or view it on GitHub.

from swift-style-guide.

The discussion is a little stale. I'm leaning towards not prescribing how to do singletons in the style guide though, but please file an issue or pull request if you feel strongly otherwise.

from swift-style-guide.