From: Asen Bozhilov on
Justin Johnson wrote:

> The only way to have a true singleton in JavaScript is to use all
> private members so that the data cannot be cloned from one object to
> another.
>
> var a = (function() {
>     var _a = 1, _b = 2;
>     return {
>         getA: function()  { return _a; },
>         setA: function(a) { _a = a;    },
>         getB: function()  { return _b; },
>         setB: function(b) { _b = b;    }
>     };
>
> })();
>
> var b = clone(a);
>
> a.setA(3);
> b.setB(4);
> console.log(a.getA(), a.getB(), b.getA(), b.getB());

If someone need copy of a singleton object there is design mistake.
That is contradiction with conception of a singleton pattern. Your
defense is not enough for unreasonable development and should not. If
there is a developer who misunderstand your concept, he always can
broke your code.


From: Lasse Reichstein Nielsen on
M A Hossain Tonu <mahtonu(a)gmail.com> writes:

>> var clone = function(o) {
>> � � var no = {};
>> � � for ( var i in o ) {
>> � � � � no[i] = o[i];
>> � � }
>> � � return no;
>>
>> }
>>
>> var a = {a: 1, b: 2},
>> � � b = clone(a),
>> � � c = a;

> a.a = 3;
> b.a = 4;
> console.log(a.a, b.a, c.a);
>
> outputs 4 4 4 they are using same memory...

No, it doesn't. The b variable holds a reference to a different object,
and it writes 3,4,3.

> cause they are copy not an unique instance....so where is the
> singelton pattern violated?

The "singleton pattern" makes no sense in a classless language.
It means that you can only create one instance of a specific class.
It has no meaning when there are no classes.
What would it be that you could only create on instance of?

/L 'You could do it with host objects, but then, you can do
anything with those'
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: VK on
On Jun 6, 2:15 pm, M A Hossain Tonu <maht...(a)gmail.com> wrote:
> Any suggestion will be highly appreciable.

The further is not a group consensus but my own private opinion.

[1] Of course there are classes in JavaScript. Like in any OO language
there are classes of things and instances of those classes of things.
Semi-hysterical "there are no classes in JavaScript!!" and tabooed
word "class" itself comes from the JavaScript childhood. Then it was a
protection mechanics against "real languages" that were laughing over
"that toy language". So the story was that "I am not primitive, I am
different! Very very different and hard to be understood by outsiders.
I am the Wrrrld's Most Misunderstood Programming Language! (c)2001
Crockford http://javascript.crockford.com/javascript.html " :-)

For the same reason the prototype-based inheritance, that is as simple
as a moo-cow, was often presented nearly as a ultimate lore with a
bunch of convoluted samples proving its complex nature.

The childhood is way over and this "protection behavior" is not
needed. There are classes and instances in JavaScript just like
everywhere else. The core difference from C-like languages is that
there we have the strict specialization: there are objects that create
new objects (classes) and there are object that do the actual job the
program is created for (instances). They are not interchangeable: one
cannot use a class to calculate 2*2=? and one cannot use an instance,
calculating 2*2=?, as a class.
In JavaScript constructor is the same first order function so
theoretically it can be used as an instance constructor or just be
called as a function. This polymorphism is purely theoretical though:
it can't be a descent code with function Foo being used in either way
in the same program, like this
var obj = new Foo();
and then some later
Foo();

[2] Your article is rather confusing by its layout. Basically you are
describing some elements of CC scope management, namely the creation
of protected properties and privileged methods. Other words instance
properties that can be accessed only over particular instance methods.
It is a commonly used practice now, but it has nothing to do with
singletons. It can be N instances of the same class with protected
properties and privileged methods. It can be a singleton without any
protected properties and privileged methods. These are simply
unrelated things. And most definitely neither first nor second has any
relation with JSON data-interchange format. What you really wrote, in
proper JavaScript terms, is "Using privileged methods in JavaScript:
how to and benefits". And if writing about Cornford-Crockford scope
management aspects it may be useful to read the original papers:
"Private Members in JavaScript" by Douglas Crockford (2001)
http://www.crockford.com/javascript/private.html
and
"Private Static Members in JavaScript" by Richard Cornford (2003)
The article is gone but still available over Wayback Machine:
http://web.archive.org/web/20031205082329/http://www.litotes.demon.co.uk/js_info/private_static.html

A nice summary can be found in this group archives in the discussion
"closures, what are they good for?" (April-May 2003)
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/793cd655ad56fe91

[3] In reference to singleton it would be a whole different article
and a different discussion. If you are interested in singletons and
not in CC scope management, let's talk about singletons.
From: M A Hossain Tonu on
The problem with that clone method, that if you have sub objects
within the obj, their references will be cloned, and not the values of
every sub object.

On Jun 6, 5:20 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
wrote:
> M A Hossain Tonu <maht...(a)gmail.com> writes:
>
>
>
> >> var clone = function(o) {
> >>     var no = {};
> >>     for ( var i in o ) {
> >>         no[i] = o[i];
> >>     }
> >>     return no;
>
> >> }
>
> >> var a = {a: 1, b: 2},
> >>     b = clone(a),
> >>     c = a;
> > a.a = 3;
> > b.a = 4;
> > console.log(a.a, b.a, c.a);
>
> > outputs 4 4 4 they are using same memory...
>
> No, it doesn't. The b variable holds a reference to a different object,
> and it writes 3,4,3.
>
> > cause they are copy not an unique instance....so where is the
> > singelton pattern violated?
>
> The "singleton pattern" makes no sense in a classless language.
> It means that you can only create one instance of a specific class.
> It has no meaning when there are no classes.
> What would it be that you could only create on instance of?
>
> /L 'You could do it with host objects, but then, you can do
>     anything with those'
> --
> Lasse Reichstein Holst Nielsen
>  'Javascript frameworks is a disruptive technology'

From: M A Hossain Tonu on
Thank you very much for your valuable suggestion. I am altering and
filling the post.

Tonu


On Jun 6, 5:27 pm, VK <schools_r...(a)yahoo.com> wrote:
> On Jun 6, 2:15 pm, M A Hossain Tonu <maht...(a)gmail.com> wrote:
>
> > Any suggestion will be highly appreciable.
>
> The further is not a group consensus but my own private opinion.
>
> [1] Of course there are classes in JavaScript. Like in any OO language
> there are classes of things and instances of those classes of things.
> Semi-hysterical "there are no classes in JavaScript!!" and tabooed
> word "class" itself comes from the JavaScript childhood. Then it was a
> protection mechanics against "real languages" that were laughing over
> "that toy language". So the story was that "I am not primitive, I am
> different! Very very different and hard to be understood by outsiders.
> I am the Wrrrld's Most Misunderstood Programming Language! (c)2001
> Crockfordhttp://javascript.crockford.com/javascript.html" :-)
>
> For the same reason the prototype-based inheritance, that is as simple
> as a moo-cow, was often presented nearly as a ultimate lore with a
> bunch of convoluted samples proving its complex nature.
>
> The childhood is way over and this "protection behavior" is not
> needed. There are classes and instances in JavaScript just like
> everywhere else. The core difference from C-like languages is that
> there we have the strict specialization: there are objects that create
> new objects (classes) and there are object that do the actual job the
> program is created for (instances). They are not interchangeable: one
> cannot use a class to calculate 2*2=? and one cannot use an instance,
> calculating 2*2=?, as a class.
> In JavaScript constructor is the same first order function so
> theoretically it can be used as an instance constructor or just be
> called as a function. This polymorphism is purely theoretical though:
> it can't be a descent code with function Foo being used in either way
> in the same program, like this
>  var obj = new Foo();
> and then some later
>  Foo();
>
> [2] Your article is rather confusing by its layout. Basically you are
> describing some elements of CC scope management, namely the creation
> of protected properties and privileged methods. Other words instance
> properties that can be accessed only over particular instance methods.
> It is a commonly used practice now, but it has nothing to do with
> singletons. It can be N instances of the same class with protected
> properties and privileged methods. It can be a singleton without any
> protected properties and privileged methods. These are simply
> unrelated things. And most definitely neither first nor second has any
> relation with JSON data-interchange format. What you really wrote, in
> proper JavaScript terms, is "Using privileged methods in JavaScript:
> how to and benefits". And if writing about Cornford-Crockford scope
> management aspects it may be useful to read the original papers:
>   "Private Members in JavaScript" by Douglas Crockford (2001)
>  http://www.crockford.com/javascript/private.html
> and
>   "Private Static Members in JavaScript" by Richard Cornford (2003)
>   The article is gone but still available over Wayback Machine:
>  http://web.archive.org/web/20031205082329/http://www.litotes.demon.co....
>
> A nice summary can be found in this group archives in the discussion
>   "closures, what are they good for?" (April-May 2003)
>  http://groups.google.com/group/comp.lang.javascript/browse_frm/thread....
>
> [3] In reference to singleton it would be a whole different article
> and a different discussion. If you are interested in singletons and
> not in CC scope management, let's talk about singletons.