Suggestion for a singleton implementation

[LiorGonnen]

Here's my suggestion for a singleton class.
The (straight forward) logic is that:
1. If someone tries to call the constructor externally before an instance exists, _getInstanceCalled will be false and the constructor will throw
2. If someone tries to call the constructor externally after an instance exists, the constructor will throw
3. ... which means you are left with only getInstance property to call the class.

public MySingleton
{
private static var _instance : MySingleton = null;
private static var _getInstanceCalled : Boolean = false;

public function MySingleton() {
if (!_getInstanceCalled || _instance != null)
throw new Error("Singleton class. Use getInstance property instead");

// Initialize your singleton here
}

public static function get getInstance() : MySingleton {
_getInstanceCalled = true;

if (_instance == null)
_instance = new MySingleton();

return _instance;
}
}
Any comments are welcome

Thanks,
Lior :)

[newblack]

The problem with this pops up if/when your sole instance is set to null:

MySingleton.getInstance() = null;
var noLongerASingleton:MySingleton = new MySingleton();

[LiorGonnen]

This is not true. 'getInstance' is a property 'getter' not a normal function (as you used it)
Trying to assign a value to it will result in a compiler error "Property is read-only"

The problem with this pops up if/when your sole instance is set to null:

MySingleton.getInstance() = null;
var noLongerASingleton:MySingleton = new MySingleton();

[Flash Gordon]

nevermind

[LiorGonnen]

Nice try :)
My opinion is that:
1. A PlayList class is not a good candidate for a singleton, you might want to replace the PlayList, and then you'd need a destroyInstance or something....
2. Generally speaking about parameter passing to a singleton: I don't think that passing the parameters using getInstance is a good approach, if parameters are needed I would either
a. have both 'createInstance(...params...)' and 'getInstance' methods
b. have a public constructor (that can be called only once) and 'getExistingInstance'.

But other than that you are perfectly right ;)

[Flash Gordon]

yea....I edited my post apparently while you were typing. A simipling adding params to your getter function shut me up ;)

Cheers
:)

[mooska]

MySingleton.getInstance() = null;
Im not sure is it possible to use setter/getter property like that ;)



http://life.neophi.com/danielr/2006/10/singleton_pattern_in_as3.html

[Assertnfailure]

Guys guys, the syntax would be
var instance = MySingleton.getInstance;

You don't call getters with paranthesis. And you can't set the property to null if there's no setter.

The problem is that "getInstance" is a verb phrase, which implies an action (ie. a method invocation). "instance" would be a more plausible name for a getter.

However, I still prefer the idea of calling a method rather than a property to retrieve the instance. If you're going to implement a design pattern, it's usually best to keep it conventional to minimize confusion.

[LiorGonnen]

Properties like in ActionScript and C#, (which are function calls in disguise) are a relatively new feature, as far as I know, maybe I'm wrong about that.
The fact that a property is not used in the "Gang of Four" (GOF) book, doesn't imply that this is not a standard way of implementing the pattern.

Bottom line guys: The idea was to present a bullet-proof singleton pattern concept for ActionScript.
Every one can use it in anyway they want, in a function call, or a property, with an 'instance' or 'getInstance' name.
Just keep your code safe :)

[Tink]

However, I still prefer the idea of calling a method rather than a property to retrieve the instance. they used getters in Flex

Application.application

[Assertnfailure]

they used getters in Flex

Application.application

I'm not saying that nobody uses getters at all....
I'm saying nobody uses getInstance as a getter

[Tink]

sorry i should have clarified, what i meant was they use getters for singletons in Flex.

Application.application is a reference to a singleton. instead of using getInstance they use a getter named 'application'.

[newblack]

This is not true. 'getInstance' is a property 'getter' not a normal function (as you used it)
lolz- are you sure you didn't edit this!?!!

and thanks st333v0, clearly my parenteses had nothing to do with my missing its getterness...

[Tink]

lolz- are you sure you didn't edit this!?!!nope it wasn't edited. i thought u had mis-read it when i looked at your comment.

Also if users edit a post it leaves a note on the post.

[Assertnfailure]

Application.application is a reference to a singleton. instead of using getInstance they use a getter named 'application'.

Ah ok. Well that's stupid then.

With all the crazy shit that's in the flex library, you can probably find an example of every conceivable anti-convention in there. Which is why I can rarely work on a Flex 2 project without having the livedocs open.

[newblack]

nope it wasn't edited. i thought u had mis-read it when i looked at your comment.

Also if users edit a post it leaves a note on the post.
it was a joke

[Tink]

Ah ok. Well that's stupid then.It's only stupid now u know its a replacement for getInstance but before it made sense and was fine?

[Assertnfailure]

It's only stupid now u know its a replacement for getInstance but before it made sense and was fine?
Yes, before it was fine because I didn't think it was a replacement for getInstance. I can't say it made sense, as I've never used Application.application before.

[dr_zeus]

Yes, before it was fine because I didn't think it was a replacement for getInstance.

I've always thought a function called getInstance in a singleton was unintuitive. Application.application is easy to understand (in context to the class it appears in) even if you don't know or care that it's a singleton.

[Assertnfailure]

If you see a method called getInstance() and you don't know what it does, then you don't know what a singleton is.

Everybody has their own perception of what's intuitive or not, and there's many different ways to achieve the same result, but the whole point of creating conventions in the first place is so everyone can interface with each other's code as easily as possible.

Arguing about conventions is quite possibly the most frustrating type of argument, because conventions came into existence for the very purpose of resolving such arguments!

[Tink]

it just didn't make sense to make a statement that something is stupid, when 10 mins earlier you thought it was fine, just because someone informed u that its a singleton.

Who cares if something is a singleton, thats the point of encapsulation right? It doesn't matter how it works internally etc, just that its easy and intuitive to work with.

[Assertnfailure]

Except its not intuitive. I only know about Application.application because you told me about it. Encapsulation is fine, but you can't expect developers to simply *not know* when an exposed design pattern is being used.

If I wanted to instantiate an application using actionscript, how am I to know that I can't use the new operator if I'm not supposed to know that application is a singleton?

[dr_zeus]

If you see a method called getInstance() and you don't know what it does, then you don't know what a singleton is.

In my opinion, it shouldn't matter if someone knows what a singleton is or not. Of course, Application.application isn't necessarily the most intuitive way to do it either. I almost wonder if singletons would feel less like a goofy hack if they were built into languages.

If I wanted to instantiate an application using actionscript, how am I to know that I can't use the new operator if I'm not supposed to know that application is a singleton?

Back to the original example presented, you'll notice that the constructor throws an error if the singleton has already been created. The error tells the developer how the singleton works, and that's the best way I've seen to show someone that it's a singleton. A better way would be if we had private/protected constructors because it would force a developer to check the documentation after they got an error from a new operator. Unfortunately, that's not in the ECMAScript standard.

Arguing about conventions is quite possibly the most frustrating type of argument, because conventions came into existence for the very purpose of resolving such arguments!

If there are arguments about a convention, that may mean that the best solution hasn't been found yet.

[Assertnfailure]

If there are arguments about a convention, that may mean that the best solution hasn't been found yet.

Out of a million coders, there will always be at least 2 that dislike a convention. Things like design patterns have matured through various languages for 30 years. It would be ridiculous to open it up as a case for argument now because you don't like the method invocation. :rolleyes:

Conventions aren't meant to represent the "best solution", they're meant to represent the "most preferred solution among a list of best solutions."

[MichaelxxOA]

I agree with Assertnfailure, it's a convention for a reason. If all you do is work freelance on your own projects this may not be an issue. Get it into a team environment and I'm sure it's going to become one.

In the end the detail is just a tad too nitty gritty for anyone to be this worried about it. getInstance() as a static method is something that will most likely bring a sense of clarity to a developer working with your code for the first time (when you are 100% inaccessible, after all that's the only time it counts right?).

I just wouldn't borrow my conventions from the Flex framework, I guess is how I'd say it.

-Michael

[dr_zeus]

It would be ridiculous to open it up as a case for argument now because you don't like the method invocation. :rolleyes:

It's always a good idea to re-examine old conventions or traditions if new ideas come along. For instance, a getter function that works like a property hasn't been around for very long in popular programming languages. Arguably, using a getter named "instance", as you mentioned earlier, would be an improvement over the function getInstance because it follows the language's own conventions more closely. In that case, someone familiar with singletons shouldn't have too much trouble transitioning.

Don't mind me, though. I just happen to enjoy debating conventions. :p

[dr_zeus]

I just wouldn't borrow my conventions from the Flex framework, I guess is how I'd say it.

At least not for singletons, right? ;)

Other than that, there's some decent code in the framework, and I've picked up some good ideas while exploring the source.

[MichaelxxOA]

At least not for singletons, right? ;)

Other than that, there's some decent code in the framework, and I've picked up some good ideas while exploring the source.


I meant I wouldn't borrow directly... lol, use any source you can as a way to learn. Just don't take any one source as the way to do it. These kinds of things can't be argued really, it's all opinion.

I haven't a thing against the Flex framework (anymore).

I prefer getInstance() because it's something that is familiar to developers. That is what conventions are for.

What is the reason for the major decrease in Java's popularity? Every version introduces some kind of learning curve, even for the professionals. Every so often someone comes along with a re-thought convention, or way of doing things, it gets implemented and then boom everyone else that already thought they had their convention has to learn a new one.

What would be the point of something being a convention if people were trying to re-think how to do it? There are times when this is necessary though, like when it will improve performance. I'm not saying that conventions are the end all.

It's nothing to get worked up about though, everyone stated their opinions, they should just be left for people to take how they want. No use arguing 'TOO' much.

If people are inspired by this, to start creating Singletons this way, then great. That is the beauty of the forums, we are all here to share our ideas, give feedback, or help other people who are trying to learn.

Michael