Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

On Sat, Feb 15, 2014 at 1:57 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson <arv@chromium.org> wrote:
>
>
>
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>
>>  On Feb 13, 2014, at 4:01 PM, Alex Russell <slightlyoff@google.com>
>> wrote:
>>
>> A closure is an iron-clad isolation mechanism for object ownership with
>> regards to the closing-over function object. There's absolutely no
>> iteration of the closed-over state of a function object; any such
>> enumeration would be a security hole (as with the old Mozilla
>> object-as-param-to-eval bug). You can't get the value of "foo" in this
>> example except with the consent of the returned function:
>>
>>
>> var maybeVendFoo = function() {
>>   var foo = 1;
>>   return function(willMaybeCall) {
>>     if (/* some test */) { willMaybeCall(foo); }
>>   }
>> };
>>
>> Leakage via other methods can be locked down by the first code to run in
>> an environment (caja does this, and nothing prevents it from doing this for
>> SD as it can pre-process/filter scripts that might try to access internals).
>>
>>
>> Caja is effective for protecting a page from code it embeds, since the
>> page can have a guarantee that its code is the first to run. But it cannot
>> be used to protect embedded code from a page, so for example a JS library
>> cannot guarantee that objects it holds only in closure variables will not
>> leak to the surrounding page...
>>
>
> That is incorrect. It is definitely possible to write code that does not
> leak to the environment. It is painful to do because like Ryosuke wrote you
> cannot use any of the built in functions or objects. You can only use
> primitives and literals. But with a compile to JS language this can be made
> less painful and in the days of LLVM to JS compilers this seems like a
> trivial problem.
>
>
> Let's assume for the sake of argument that there was actually a practical
> way to do this for nontrivial code[*]. Even if that were the case, it would
> not be relevant to the way in which today's JS programs use closures. They
> find closures useful even without a transpiler to a primitives-only subset
> of the language. So one cannot claim the value of closures for
> encapsulation follows from this theoretical possibility.
>

This misses a good chunk of cultural JS practice (which, I should note,
still isn't a substitute for the previously requested use-cases and example
code): in many frameworks, closure-captured state is considered to be
"hostile" as it prevents monkey-patches and makes extension difficult.
Many, instead, lean on convention (some form of "_"-based prefix/suffix) to
denote semi-private state.

Closures most frequently find use in areas where JS's lexical binding
leaves much to be desired, (ab)using the function context as a way to
create new lexical bindings.

Arguing about them as a containment structure without this cultural context
isn't particularly enlightening.

Looking forward to hearing more about possible uses for the type of
encapsulation you're proposing.

Regards


> Regards,
> Maciej
>
>
> * - And really, it is not that practical. Many algorithms require a
> variable-sized data structure, or one that is indexable, or one that is
> associative - and you can't do any of that with only primitives and a fixed
> set of variable slots. And you can't do anything to a primitive that would
> potentially invoke a method call explicitly or implicitly, which includes
> such things as number-to-string conversion, using functions on the Math
> object on numbers, and the majority of things you would do to a string
> (such as converting to/from char codes). What remains is pretty narrow.
> This is setting aside that you would not be able to do anything useful to
> the outside world besides return a value. For reference, the LLVM-to-JS
> compilers that exist make major use of non-primitives, in particular
> Emscripten uses a giant typed array to represent memory.
>
>