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

* Maciej Stachowiak wrote:
>Type 2 is not meant to be a security mechanism. It is meant to be an 
>encapsulation mechanism. Let me give a comparison. Many JavaScript 
>programmers choose to use closures as a way to store private data for 
>objects. That is an encapsulation mechanism. It is not, in itself, a 
>hard security mechanism. If the caller can hook your global environment, 
>and for example modify commonly used Object methods, then they may force 
>a leak of your data. But that does not mean using closers for data 
>hiding is a "fig-leaf" or "attractive nuisance". It's simply taking 
>access to internals out of the toolset of common and convenient things, 
>thereby reducing the chance of a caller inadvertently coming to depend 
>on implementation details.

An analogy for the above would be a programming environment where your
access to a private data member via `example.private_member` is denied
but you can still use the runtime environment's reflection API to get
to it. In a sense, marking a data member private then is just hard-to-
miss documentation of the API contract. I think that is sensible, but
it is also quite far away from your description of "Type 2"

  Encapsulation against deliberate access - no API is provided which
  lets code outside the component poke at the shadow DOM. Only internals
that the component chooses to expose are exposed."

since the reflection API is being provided in my analogous example, and
it leaves out mention of "common" and "convenient" which are central to
your description above. I can easily agree that "use classes maybe?" is
an insufficient answer to requests for this kinder, gentler version of
"Type 2".
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 13 February 2014 23:39:23 UTC