Prev: capture external js filename
Next: Dynamically refresh (update) JSP webpage when JMS notification is received
From: Dmitry A. Soshnikov on 3 Feb 2010 09:14
On Feb 2, 11:56 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:

[snip]

> whereas in the other one, the
> implementation is exposed and could be manipulated by malicious or
> clueless use, via, say:
>

The first (and main) thing to understand about encapsulation should be
that encapsulation is an increasing of an abstraction and a helper
(firstly) for the programmer. It should not be treated as a security
technique, as it's not. That is for "malicious".

About the "clueless" - yeah, encapsulation will help to manage the
code more carefully. Simple (public) API for export - is a good way to
concentrate on the tasks for those this API was deigned and do not
think (much ;)) about the helper functionality which is encapsulated
(read - abstracted) from the user of that API.

Simple function - is an encapsulation (abstraction): when you use
Math.round(...) - it doesn't matter, what does this abstraction does
inside. But for the outside it returns acceptable mathematical result.

And access control ability such as "public", "private" and "protected"
is a useful syntactic sugar provided by some implementations. this
"sugar" is really useful in main encapsulation goal - to help the
programmer itself, to build this public API, abstracting
(encapsulating) "non-interesting" internal (private) things for the
end user. But it's not about protection from malicious access (as
examples: Python or Ruby, where there're all that "public" and
"privates" but there're still abilities to get the access to
encapsulated data if needed).

And for the security reasons the completely different techniques are
used.

>
> But the closure technique also has the advantage that the
> implementation doesn't leak at all
>

Yeah, simple additional (helper) context for encapsulation (usually as
an (anonymous) function expression) - is a good decision for avoiding
polluting the outside scope. Although, in some (versions of)
implementations there's ability to get access to internal activation
object using `eval' and modify "private" var's.

/ds
From: Scott Sauyet on 3 Feb 2010 10:41
On Feb 3, 1:11 am, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
wrote:
> Personally I would do it like:
>
>  var openWin = (function() {
>    var myWin;
>     return function(aURL) {
>       if (!myWin || myWin.closed ) {
>         myWin = window.open(aURL, 'myWin');
>      } else {
>        myWin.location.href = aURL;
>        myWin.focus();
>       }
>       return myWin;
>     };
>   })();

This is the method I use most often, and from what Garrett said, there
don't seem to be any performance issues in using it. There is
something to be said for Garrett's function re-writing, though, too,
which I might write a little more explicitly like this:

var openWin = function(aURL) {
var myWin;
openWin = function(aURL) {
if (!myWin || myWin.closed ) {
myWin = window.open(aURL,'myWin');
} else {
myWin.location.href = aURL;
myWin.focus();
}
return myWin;
};
return openWin(aURL);
};

One advantage to this is that before this function is called, there is
no function call performed to define it and no variable declaration
made. Certainly this is not an issue with such minor initialization,
but for a function that possibly would never be called and that
requires substantial initialization, I can easily see an advantage to
this. On the other hand, if this initialization is time-consuming,
perhaps waiting for a user-initiated event to run it would be
problematic too.

As to speed, the two techniques would have similar scope chains,
correct?

Thanks everyone for your input!

-- Scott
From: Scott Sauyet on 3 Feb 2010 11:01
On Feb 3, 9:14 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> On Feb 2, 11:56 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> [snip]
>
>> whereas in the other one, the
>> implementation is exposed and could be manipulated by malicious or
>> clueless use, via, say:
>
> The first (and main) thing to understand about encapsulation should be
> that encapsulation is an increasing of an abstraction and a helper
> (firstly) for the programmer. It should not be treated as a security
> technique, as it's not. That is for "malicious".

Perhaps you're right. I'm not convinced, though, that there is no
good reason to try to protect my code as best I can against even
intentional misuse.


> About the "clueless" - yeah, encapsulation will help to manage the
> code more carefully. Simple (public) API for export - is a good way to
> concentrate on the tasks for those this API was deigned and do not
> think (much ;)) about the helper functionality which is encapsulated
> (read - abstracted) from the user of that API.

This is of course the main point. A clean API is much more important
than a clean implementation.


>> But the closure technique also has the advantage that the
>> implementation doesn't leak at all
>
> Yeah, simple additional (helper) context for encapsulation (usually as
> an (anonymous) function expression) - is a good decision for avoiding
> polluting the outside scope. Although, in some (versions of)
> implementations there's ability to get access to internal activation
> object using `eval' and modify "private" var's.

Really, I've not seen that. Can you point me to further information?

Thanks,

-- Scott
From: Dmitry A. Soshnikov on 3 Feb 2010 12:22
On Feb 3, 7:01 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:

[...]

>
> >> But the closure technique also has the advantage that the
> >> implementation doesn't leak at all
>
> > Yeah, simple additional (helper) context for encapsulation (usually as
> > an (anonymous) function expression) - is a good decision for avoiding
> > polluting the outside scope. Although, in some (versions of)
> > implementations there's ability to get access to internal activation
> > object using `eval' and modify "private" var's.
>
> Really, I've not seen that.  Can you point me to further information?
>

For example, in Spidermonkey version 1.7:

var a = (function () {
var x = 10; // "private"
return function () { // public "API"
alert(x);
};
})();

a(); // 10
eval('x = 20', a);
a(); // 20

Another encapsulation technique in ECMAScript is a simple anonymous
object (not a function object) which runs its initialization method
right after creation, which in its turn makes all the job by creating
public/global properties. This technique is like an anonymous function
context (and actually it is - here .initialize method play this role),
but also let to organize some additional helper data not only in this
helper context:

({

... // other stuff

initialize: function () {
var y = 20;
global.publicMethod = function () {
alert(y);
};
}

... // other helper stuff

}).initialize();

publicMethod(); // 20

/ds
From: Dmitry A. Soshnikov on 3 Feb 2010 15:27
On Feb 3, 8:22 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> On Feb 3, 7:01 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
>
> [...]
>
>
>
> > >> But the closure technique also has the advantage that the
> > >> implementation doesn't leak at all
>
> > > Yeah, simple additional (helper) context for encapsulation (usually as
> > > an (anonymous) function expression) - is a good decision for avoiding
> > > polluting the outside scope. Although, in some (versions of)
> > > implementations there's ability to get access to internal activation
> > > object using `eval' and modify "private" var's.
>
> > Really, I've not seen that.  Can you point me to further information?
>
> For example, in Spidermonkey version 1.7:
>
> var a = (function () {
>   var x = 10; // "private"
>   return function () { // public "API"
>     alert(x);
>   };
>
> })();
>
> a(); // 10
> eval('x = 20', a);
> a(); // 20
>

Addition: it is fair for any implementation which allows access to the
activation object (and its properties) of a function.

/ds
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: capture external js filename
Next: Dynamically refresh (update) JSP webpage when JMS notification is received