Singleton

[Peter Michaux]

Re: Singleton

On May 24, 8:58 am, Ugo <priv...@nospam .itwrote:

>The best way of doing something depends at least in part on what it is
>you are trying to do.
A generic way to create a singleton object

I doubt that is what Richard meant by "what it is you are trying to
do". You are more likely trying to "implement a tabbed pane widget" or
"send user data to the server". Unless this is just an academic
exercise.

>
all this things :P
>

A generic way to create a singleton object with global access is to
use a object literal.

>

var someSingleton = {
someProperty: function() {},
someOtherProper ty: 55
};

>
But, in this way I can not to declare "private" variables/methods in an
elegant way:
>
I don't like it:
>
var singleton;
>
(function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}
>
// Obj
singleton = {
hi : b,
a: a
};
>
})();

Why don't you "like it"? Because it does not involve a constructor
function? Because it is not like Java? These seem like unfortunates
reason to avoid the simplest most direct technique to achieve your
goal. What you have written above is one normal way to write a
JavaScript singleton and is far simpler than your previous code
examples.

I am not always so concerned with this sort of closure "privacy" and
would just write

var singleton = {
_a: 1,
hi: function() {alert('hi');}
};

Some folks argue against the underscore privacy convention but I think
they are fooling themselves that things can be protected in
JavaScript. Someone could come along and reassign to the singleton
variable and destroy everything anyway.

Peter

[VK]

Re: Singleton

On May 24, 8:13 pm, VK <schools_r...@y ahoo.comwrote:

On May 24, 7:58 pm, Ugo <priv...@nospam .itwrote:
>
>
>

>>The best way of doing something depends at least in part on what it is
>>you are trying to do.
>A generic way to create a singleton object
I doubt that is what Richard meant by "what it is you are trying to
do". You are more likely trying to "implement a tabbed pane widget" or
"send user data to the server". Unless this is just an academic
exercise.

>

all this things :P

>

A generic way to create a singleton object with global access is to
use a object literal.

>

var someSingleton = {
someProperty: function() {},
someOtherProper ty: 55
};

>

But, in this way I can not to declare "private" variables/methods in an
elegant way:

>

I don't like it:

>

var singleton;

>

(function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}

>

// Obj
singleton = {
hi : b,
a: a
};

>

})();

>
The way I'm using most often - without any claims that it is the best
out of anything:
>
function MySingleton() {
if (this == self) {
window.alert('C onctructor called as a function');
return MySingleton;
}
else if (
!!($isInstantia ted.flag) ||
(this instanceof MySingleton) ||
(MySingleton.is PrototypeOf(thi s))
) {
window.alert('O nly one instance is allowed');
return mySingleton;
}
else {
// instantiate your singleton
// with methods and properties
// ...
this.toString = $toString;
$isInstantiated .flag = true;
}
function $isInstantiated () {
return arguments.calle e.flag;
}
function $toString() {
return ''.concat(
'function mySingleton() {\n',
' [native code]\n',
'}'
);
}
>
}
>
The benefits as I see them:
1) It is much lesser convoluted as function expression ways.
Respectively it is easier to read, to maintain and to avoid parasite
closures.
2) It allows to distinct different "not allowed" situation so to
provide more informative errors - in a real case window.alert replaced
by throw new Error of course.
3) it prevents or at least makes much harder to use reliably runtime
cloning over source code dumping and reusing in eval or new Function.

A few errors made while pulling out the code and readjusting for
posting, sorry. The corrected version would be:

function MySingleton() {
if (this == self) {
window.alert('C onctructor called as a function');
return MySingleton;
}
else if (
!!($isInstantia ted.flag) &&
((this instanceof MySingleton) ||
(MySingleton.is PrototypeOf(thi s)))
) {
window.alert('O nly one instance is allowed');
return MySingleton;
}
else {
// instantiate your singleton
// with methods and properties
// ...
this.toString = $toString;
$isInstantiated .flag = true;
}
function $isInstantiated () {
return arguments.calle e.flag;
}
function $toString() {
return ''.concat(
'function mySingleton() {\n',
' [native code]\n',
'}'
);
}
}

[Ugo]

Re: Singleton

[cut]

>I don't like it:
>var singleton;
>(function()
>{
> // "privare" prop
> var a = 1;
> // "private" method
> function b( )
> {
> alert('hi');
> }
> // Obj
> singleton = {
> hi : b,
> a: a
> };
>})();

>
Why don't you "like it"? Because it does not involve a constructor
function? Because it is not like Java? These seem like unfortunates
reason to avoid the simplest most direct technique to achieve your
goal. What you have written above is one normal way to write a
JavaScript singleton and is far simpler than your previous code
examples.

But, reconsidering.. .
it's applicatively equal to my original code:
[by step]
it'was the same:


var singleton = (function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}
// Obj
return {
hi : b,
a: a
};
})();

that is analog to:

var singleton = (function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}
// Obj
return new function()
{
this.hi = b;
this.a = a;
};
})();

my origina code

[Peter Michaux]

Re: Singleton

On May 24, 3:02 pm, Ugo <priv...@nospam .itwrote:

[cut]
>
>
>

I don't like it:
var singleton;
(function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}
// Obj
singleton = {
hi : b,
a: a
};
})();

>

Why don't you "like it"? Because it does not involve a constructor
function? Because it is not like Java? These seem like unfortunates
reason to avoid the simplest most direct technique to achieve your
goal. What you have written above is one normal way to write a
JavaScript singleton and is far simpler than your previous code
examples.

>
But, reconsidering.. .
it's applicatively equal to my original code:
[by step]
it'was the same:
>
var singleton = (function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}
// Obj
return {
hi : b,
a: a
};
>
})();
>
that is analog to:
>
var singleton = (function()
{
// "privare" prop
var a = 1;
// "private" method
function b( )
{
alert('hi');
}
// Obj
return new function()
{
this.hi = b;
this.a = a;
};
>
})();
>
my origina code

Given the original post...

On May 7, 1:42 am, Ugo <priv...@nospam .itwrote:

Hi guys,
>
how do you make a singleton access class?
>
Do you know a better way of this one:

[snip]

I believe I have presented several options that I think are better and
actually are standard JavaScript patterns?

What is it you want from the group?

Peter

[Ugo]

Re: Singleton

[cut]

[snip]
>
I believe I have presented several options that I think are better and
actually are standard JavaScript patterns?
>
What is it you want from the group?

Sorry, I didn't want to seem ungrateful :(
I'm very happy about "several options" were listed...

In addition, I wanted to adopt the guide lines of GoF's pattern, and
parhaps I succeed:


var SingletonClass;
(function()
{
var instance;
SingletonClass = function( )
{
if( this == window )
{
alert( 'This is no function!' );
return;
}
// else if( this.prototype != SingletonClass. prototype )
else if( ! ( this instanceof SingletonClass ) )
{
alert( 'Che cavolo stai dicendo Willis!' );
return;
}
else if( instance )
return instance;
else
instance = this;

this.$ = 'hi';
this.f = function()
{
alert( this.$ );
}
}
SingletonClass. getInstance = function( )
{
return instance || ( instance = new SingletonClass( ) );
}
})();

[VK]

Re: Singleton

On May 25, 11:01 am, Ugo <priv...@nospam .itwrote:

The solution is unnecessary convoluted by extra closures not bearing
any functional load. That is IMHO and OK if someone just loves
closures so collecting different species of them like orchids :-)

The possible failure point is in "not allowed" checks like:

if( this == window )
{
alert( 'This is no function!' );
return;
}
// else if( this.prototype != SingletonClass. prototype )
else if( ! ( this instanceof SingletonClass ) )
{
alert( 'Che cavolo stai dicendo Willis!' );
return;
}

If a function is called as constructor, thus in the context "new
SingletonClass" or "new DerivedSingleto nClass", then the return value
_must_ be an object. If it tries to return a primitive value then such
return value will be silently disregarded and the current value of
"this" will be returned instead. This behavior is by design and by
ECMAScript specs.
This way say having:
else if (
!!($isInstantia ted.flag) &&
((this instanceof MySingleton) ||
(MySingleton.is PrototypeOf(thi s)))
) {
window.alert('O nly one instance is allowed');
// WRONG:
return;
}
}
your constructor doesn't return undefined as one would possibly expect
but "this" value, so still a new instance just not fully initialized
by properties and methods.

To overcome that in "not allowed" situations you have either:
1) return a reference to the constructor:
return SingletonClass;
2) throw Error _and_ return a reference to the constructor to
eliminate any possible "resume next" attempts.
3) return false wrapped into Boolean object for further condition
checks:
return new Boolean;

[Lasse Reichstein Nielsen]

Re: Singleton

Ugo <privacy@nospam .itwrites:

In addition, I wanted to adopt the guide lines of GoF's pattern, and
parhaps I succeed:
>
>
var SingletonClass;
(function()
{
var instance;
SingletonClass = function( )
{
if( this == window )
{
alert( 'This is no function!' );
return;
}
// else if( this.prototype != SingletonClass. prototype )
else if( ! ( this instanceof SingletonClass ) )
{
alert( 'Che cavolo stai dicendo Willis!' );
return;

....

SingletonClass. getInstance = function( )
{
return instance || ( instance = new SingletonClass( ) );
}
})();

Seems like massive overkill, probably due to not having stated
your requirements precisely.

I'd just do:

var SingletonClass = (function(){
var instance = { $ : 'hi', f : function() { alert(this.$); } };
return function() {
return instance;
}
})();

Or, if you really, really require lazy construction:

var SingletonClass = (function() {
var instance;
function createInstance( ) {
return {
$: 'hi',
f: function f() { alert(this.$); }
};
}
// or SingletonClassC onstructor.prot otype.f = function(){aler t(this.$);};
return function() {
return instance || (instance = createInstance( ));
};
})();


You are trying to use class based patterns in a prototype based
language. A singleton type is only necessary in a class based language
because objects needs a type. In a prototype based language, you
can create an object directly, so there is no need to introduce
an otherwise unnecessary type for a single object.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Lasse Reichstein Nielsen]

Re: Singleton

Lasse Reichstein Nielsen <lrn@hotpop.com writes:

I'd just do:

Ok, I too would actually just do:

var singleton = {
$: 'hi,
f: function() { alert(this.$); }
}

Notice that this is how the Math object works: just a plain object,
no constructor, "type" or "class" at all.
(As opposed to how, e.g., Java does it, where there is a Class with
all static methods).

You want a single object. You don't need a "type" with a single
instance for that. That's what comes from thinking in classes,
and wanting every object to have a class. Javascript does not
need that.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Re: Singleton

On May 25, 3:42 pm, Lasse Reichstein Nielsen <l...@hotpop.co mwrote:

In a prototype based language, you
can create an object directly, so there is no need to introduce
an otherwise unnecessary type for a single object.

From a clean pattern point of view it is arguable IMHO. If there is an
object distinctly different from the generic Object then why not to
introduce a specific constructor for it? Besides, the singleton can be
the privileged consumer of other objects' methods where it would be
more convenient to check if (Consumer instanceof MySingleton) rather
than using some workaround checks.

About the overwhelming "closuring" I do agree but it is just the Java/
C-way AFAIK. "The encapsulation is above everything else" -
inheritance, memory leaks, resource consuming - nothing is matter as
long as it is possible to encapsulate yet another chunk into
something. With a CS graduate - so full 4-6 years cycle of such
"training" - not too much possible to do besides nice side advises to
be disregarded :-)

[Lasse Reichstein Nielsen]

Re: Singleton

VK <schools_ring@y ahoo.comwrites:

On May 25, 3:42 pm, Lasse Reichstein Nielsen <l...@hotpop.co mwrote:

>In a prototype based language, you
>can create an object directly, so there is no need to introduce
>an otherwise unnecessary type for a single object.

>
From a clean pattern point of view it is arguable IMHO. If there is an
object distinctly different from the generic Object then why not to
introduce a specific constructor for it?

How is it different from a generic object? It has properties, and
that's all that really matters. The Math object does fine in this way.
No need for a constructor, because there is no need to construct
any more!

Besides, the singleton can be the privileged consumer of other
objects' methods where it would be more convenient to check if
(Consumer instanceof MySingleton) rather than using some workaround
checks.

Why check at all? Just call the method and document that objects
passed here should have such a method.
(An it's not like you can't circumvent the singleton'ness anyway,
if you really want to, or change the properties of the singleton
object).


The problem with the Singleton (anti-)pattern is that it shouldn't
be visible. If it makes sense to have a type, then there is no
reason to restrict to just one instance at the design level.
The implementation might only need one (but experience tells me
that, e.g., testing usually requires alternatives).

The singleton idea combines two concerns into one class: The behavior
of the class and that there should be a single designated instance
that an application should use.

These two concerns could just as easily be separated into two
classes: the class itself and a toolbox/factory class for controlling
instancing.
<URL:http://www.ibm.com/developerworks/webservices/library/co-single.html>

Hmm, guess I'm just rambling against singletons in general.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Re: Singleton

On May 25, 5:11 pm, Lasse Reichstein Nielsen <l...@hotpop.co mwrote:

From a clean pattern point of view it is arguable IMHO. If there is an
object distinctly different from the generic Object then why not to
introduce a specific constructor for it?

>
How is it different from a generic object? It has properties, and
that's all that really matters. The Math object does fine in this way.
No need for a constructor, because there is no need to construct
any more!

Well, it doesn't always do _everything_ what one needs, let's do not
exaggerate ;-)
Just off my head it is often irritating that some important math
values are stored in Number and some in Math. In a rush coding I keep
mixing where to get what. So one can have a Math based derivative for
say BigMath calculations:

function BigMath() {
this.MAX_VALUE = Number.MAX_VALU E;
this.MIN_VALUE = Number.MIN_VALU E;
// other properties
}
BigMath.prototy pe = Math;

var m = new BigMath;
alert(m.MAX_VAL UE);
alert(m.PI);

Besides, the singleton can be the privileged consumer of other
objects' methods where it would be more convenient to check if
(Consumer instanceof MySingleton) rather than using some workaround
checks.

>
Why check at all?

Because some methods have to be called only in a certain way and from
certain consumers. Such need happens, at least to me.

Just call the method and document that objects
passed here should have such a method.
(An it's not like you can't circumvent the singleton'ness anyway,
if you really want to, or change the properties of the singleton
object).

Oh definitely, anything can be broken or reverse-engineered. I do not
agree though that it is the reason to have everything as generic
Object instances and just keep dumping / removing properties as the
need goes. It may be fine for some form validator, but for a rich
application it will soon become a maintenance nightmare IMO.

....

Hmm, guess I'm just rambling against singletons in general.

Looks like to me too :-) Bad life experience with them?

[Peter Michaux]

Re: Singleton

On May 25, 12:01 am, Ugo <priv...@nospam .itwrote:

[cut]
>

[snip]

>

I believe I have presented several options that I think are better and
actually are standard JavaScript patterns?

>

What is it you want from the group?

>
Sorry, I didn't want to seem ungrateful :(
I'm very happy about "several options" were listed...
>
In addition, I wanted to adopt the guide lines of GoF's pattern, and
parhaps I succeed:

[snip convoluted code]

I read in the last few days that, when asked, Eric Gamma says the two
patterns he would no longer include in "Design Patterns" are the
Visitor and Singleton patterns. I don't have a reference for this.
Search Reddit. The justification is these patterns are too complex for
what they provide. In the case of the Singleton, a global variable can
do the job. JavaScript is particularly well suited for a global
singleton pattern. I think if you don't have extraordinary
circumstances then it is always best to program a language in a way
that is natural for that language. The other option is imposing design
patterns from languages that have deficiencies. JavaScript doesn't
have singleton deficiencies but does have class-based inheritance
deficiencies, for example.

Peter

[Richard Cornford]

Re: Singleton

Peter Michaux wrote:

On May 23, 7:22 am, Ugo wrote:

>>>how do you make a singleton access class?
>>How do you define a "singleton access class"?

>>
>i wanted a function/object which restricts the instantiation
>of one my object one time and which it ables one global access
>>

>>>Do you know a better way of this one:

>>

>>The best way of doing something depends at least in part on
>>what it is you are trying to do.

>>
>A generic way to create a singleton object

>
I doubt that is what Richard meant by "what it is you are trying
to do". You are more likely trying to "implement a tabbed pane
widget" or "send user data to the server".

Those would not be the types of things that I meant. They are too far
detached from their own implementation details to say anything about
what is wanted from this 'singleton' object that might constrain its
implementation.

Unless this is just an academic exercise.

It would not mater if it was an academic exercise.

A generic way to create a singleton object with global access
is to use a object literal.
>
var someSingleton = {
someProperty: function() {},
someOtherProper ty: 55
};

Quite right. From that simplest possible starting point there is a huge
spectrum of possible implementations running up to the ludicrously
elaborate and complex. For every step away from that simple starting
point there should be a purpose/justification/reason, and it should be
possible for the person taking that step to state what that was. And so
is it what is wanted from the object that becomes the guide as to which
steps are taken to achieve it.

Richard.

[Richard Cornford]

Re: Singleton

Ugo wrote:

>>how do you make a singleton access class?

>How do you define a "singleton access class"?

>
i wanted a function/object which restricts the instantiation
of one my object one time and which it ables one global access

Which, as Peter pointed out, is actually extremely simple to achieve.

>>Do you know a better way of this one:

>>
>The best way of doing something depends at least in part on
>what it is you are trying to do.

>
A generic way to create a singleton object

Why a "generic way"? Are you writing a javascript code generator that
needs to insert other code into a structure that will accommodate all
possibilities? Otherwise being generic is probably not that good an
idea.

(and if it's possible I'd like
to adopt the GoF's "roles" - applyed to JS)

Generally it seems to be possible to do anything you can imagine with
javascript, but being able to do something is not a good enough reason
for doing it in itself.

>>var singletonClass = (function( )
>>{
>> // Private variable
>> var instance = null;

>>
>There is little point in assigning null to this variable as its
>default undefined value will be just as false as the null value
>when you test it with - !instance -.

>
IMHO, (new myClass()) can not be null|false|unde fined..
so that initialization was good

<snip>

I cannot tell what you mean from that. Assigning null is a pointless
thing to do in this case.

Richard.

[Richard Cornford]

Re: Singleton

Ugo wrote:
<snip>

>I believe I have presented several options that I think are
>better and actually are standard JavaScript patterns?
>>
>What is it you want from the group?

>
Sorry, I didn't want to seem ungrateful :(
I'm very happy about "several options" were listed...
>
In addition, I wanted to adopt the guide lines of GoF's pattern,
and parhaps I succeed:
>
var SingletonClass;
(function()

Separating the global variable declaration from the code that
initialises it is probably not a good idea in this case. In copying this
code from place to place you risk the two becoming separate.

{
var instance;
SingletonClass = function( )
{
if( this == window )
{
alert( 'This is no function!' );
return;
}
// else if( this.prototype != SingletonClass. prototype )
else if( ! ( this instanceof SingletonClass ) )
{
alert( 'Che cavolo stai dicendo Willis!' );
return;
}

What utter nonsense. If you must have a constructor (which itself does
not make much sense if it is you intention that only one object will
ever be instantiated) and you don't want it called from other/external
code, and you are already using the inline execution of a function
expression to create a private scope, then don't mess around writing all
this code to check for misuse. Just leave the constructor in the private
scope were the external code cannot see and so cannot call it.

<snip>

this.$ = 'hi';

<snip>

The language specification for javascript (ECMA 262) states that the $
symbol "is intended for use only in mechanically generated code".

Richard.