From: VK on
On Jun 6, 2:47 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote:
> If someone need copy of a singleton object there is design mistake.

One can clone an object, but it is not possible to clone a closure
state, so it is not possible to get access to the actual protected
member values other way than using privileged methods. That is the
core idea of CC, see
"Private Members in JavaScript" by Douglas Crockford (2001)
http://www.crockford.com/javascript/private.html

Again, OP used a misleading title for the article, it is all about
protected members and privileged methods. Singletons and the
"singleton pattern" has no relation with the topic of discussion.
Singletons in JavaScript are mainly used at the script start stage,
when a bunch of environment testing and instantiation has to be done.
To keep the namespace clean afterworlds, it is often wrapped into
anonymous function:

(function(){
// DO stuff
})();

or equivalent:

(function(){
// DO stuff
}());

If one needs to get a permanent single instance of something and then
to eliminate the possibility of creating new instances, then by KISS
the simplest is just to eliminate the constructor:

var foo = new Foo();
Foo = null;
foo.constructor = null;

JavaScript function being called as constructor may return anything
instead of new instance, as long as it is typeof object. That allows
to create singletons, doubletons, tripletons etc. but I hope I will
never see it in a real code.

From: Asen Bozhilov on
VK wrote:
> Asen Bozhilov wrote:
>
> > If someone need copy of a singleton object there is design mistake.
>
> One can clone an object, but it is not possible to clone a closure
> state, so it is not possible to get access to the actual protected
> member values other way than using privileged methods.

That is depend on implementation, some implementations provide access
to internal [[Scope]] property. For example Rhino, there is
`__parent__' property which is mimic of [[Scope]]. So I can get
reference to VO associated with execution context in which some
Function Declaration/Expression is evaluated.

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 aVO = a.getA.__parent__;
for (var i in aVO) {
print(i);
}

The output in Rhino 1.7 from code above is:

arguments
_a
_b


From: Dmitry A. Soshnikov on
On 06.06.2010 19:01, VK wrote:
> On Jun 6, 6:52 pm, Asen Bozhilov<asen.bozhi...(a)gmail.com> wrote:
>> That is depend on implementation, some implementations provide access
>> to internal [[Scope]] property. For example Rhino, there is
>> `__parent__' property which is mimic of [[Scope]]. So I can get
>> reference to VO associated with execution context in which some
>> Function Declaration/Expression is evaluated.
>>
>> 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 aVO = a.getA.__parent__;
>> for (var i in aVO) {
>> print(i);
>>
>> }
>>
>> The output in Rhino 1.7 from code above is:
>>
>> arguments
>> _a
>> _b
>
> That is an important info, thank you. So Rhino breaks any
> encapsulation attempts and cannot be used for some commercial projects
> where encapsulation is really a must.

Don't understand an encapsulation incorrectly. This is less about
security, and more about increasing of an abstraction ;)

For details: <URL: http://bit.ly/am38pU>
About __parent__: <URL: http://bit.ly/9L1hWe>

Dmitry.


From: VK on
On Jun 6, 8:02 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> Don't understand an encapsulation incorrectly. This is less about
> security, and more about increasing of an abstraction ;)

Well, JavaScript never cared about abstraction and other theoretical
stuff, so the only way it could understand encapsulation is by
interpreting it in access restriction / data security terms :-) Which
is IMHO the original purpose of encapsulation in the first case. The
global abstraction logic is secondary, to make CS students to use
encapsulation instinctively by the end of the university.

From: Dmitry A. Soshnikov on
On 06.06.2010 20:22, VK wrote:
> On Jun 6, 8:02 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com>
> wrote:
>> Don't understand an encapsulation incorrectly. This is less about
>> security, and more about increasing of an abstraction ;)
>
> Well, JavaScript never cared about abstraction and other theoretical
> stuff,

Why so? JS has its way where some ideas are from other languages and
from the general theory.

> so the only way it could understand encapsulation is by
> interpreting it in access restriction / data security terms :-)

No, it's not.

> Which
> is IMHO the original purpose of encapsulation in the first case.

It is good, though, that you use "IMHO" acronym in this case. Because
again, the main purpose of the encapsulation is a to encapsulate (to
abstract) from a user some /auxiliary data/ which participate to provide
some public data, the public interface (API).

If in future the public API will be changed, then the /ability to
localize and predict the internal (encapsulated) places of the needed
changes with the minimum of expenses/ -- is the /main/ purpose of the
encapsulation.

> The
> global abstraction logic is secondary,

It is good to use "IMHO" word here too.

> to make CS students to use
> encapsulation instinctively by the end of the university.

An encapsulation of some entities can be related e.g. with a simple
function. Thus, when you use e.g. Math.round(...) you don't think about
what is "round" and how is it implemented; you just use (call) it -- the
implementation is hidden (abstracted) from you.

So if a student understands an encapsulation as a measure for exactly
security hiding -- he understands it incorrectly.

P.S.: regarding __parent__ by the way, it is very convenient to use it
to make a "private" concept usable via the naming convention with the
leading underscore -- http://gist.github.com/363056

P.S.: I don't wanna to make a big off-topic in the thread related with
"JSON Style JavaScript Class/Object declaration". So, if you want, you
can make separate thread to make the discussion more relevant with the
thread title.

Dmitry.