Document privacy model #137

littledan · 2018-08-07T10:55:59Z

As discussed in #136, this is an important missing piece of documentation. cc @allenwb @erights

@allenwb

As discussed in #136, this is an important missing piece of documentation. cc @allenwb @erights

ljharb · 2018-08-07T14:44:24Z

PRIVACY_MODEL.md

+
+Previous documentation used the term "hard private" to explain the guarantees, but that term may lead some to false conclusions. Here, we use the term *hidden*, defined as follows:
+
+> A class element is *hidden* with the syntax `#name`, which makes it inaccessible except to those granted explicit access to it.


also, it makes its presence unobservable - this is important too.

Right, will add this.

ljharb · 2018-08-07T14:44:49Z

PRIVACY_MODEL.md

@@ -0,0 +1,61 @@
+This proposal introduces new metaprogramming concepts on private fields and methods. This document describes the invariants, guarantees and scope of this privacy as a whole, in light of this feature.
+
+## Private fields and methods are *hidden*


I don’t personally find the term “hidden” clear; hidden things can be found, private things can’t.

I'd like to avoid the term "hard private" due to both the concerns @allenwb raised, and the fact that it sounds a little funny. Do you have an idea for another term?

It’s unfortunate that other languages have ruined “private” with “not actually private”, because tbh that’s really the best term.

How about going the verbose route: “unobservable and inaccessible”?

How would "inaccessible" be? I think we need to create a piece of jargon that we can make use of easily.

hmm, i dunno - "phantom", like a phantom limb?

ljharb · 2018-08-07T14:45:29Z

PRIVACY_MODEL.md

+- Decorating an element, e.g., in `class { @dec #x; #y; }`, `@dec` can see `#x` but not `#y`.
+- Decorating a class containing the element, e.g., in `@dec class { #x; #y; }`, `@dec` can see `#x` and `#y`.
+
+Future proposals may also grant access to hidden elements, but this will always be through a mechanism which is syntactically apparent; implicit access will never be granted. For example, a `protected` contextual keyword could be added to classes which grants access to subclasses, and this access grant would be similar to that which decorators do.


I think this is a poor choice of example that will distract from the point being made. Can we pick a less controversial one?

Sure, do you have any suggestions? Honestly I personally think decorators will be enough, so it's hard for me to think of an example that I actually want to go towards.

i suppose we could have some kind of grant(otherFunction) syntax? I also agree that decorators would be enough; maybe the example should just be omitted entirely?

I'm not sure what you mean by grant.

I'd like to make a statement about language evolution. Do you think I should omit this statement entirely? Or, do you have an idea for how to rephrase it?

I think the statement is fine; I'm concerned about the specific example.

ljharb · 2018-08-07T15:57:27Z

PRIVACY_MODEL.md

+
+Previous documentation used the term "hard private" to explain the guarantees, but that term may lead some to false conclusions. Here, we use the term *hidden*, defined as follows:
+
+> A class element is *hidden* with the syntax `#name`, which makes it inaccessible (for reads, writes and observing its presence) except to those granted explicit access to it.


Oxford comma :-p

I'm not attempting to match the spec's style here.

jridgewell · 2018-08-07T18:41:43Z

PRIVACY_MODEL.md

+        for (let i = 0; i < descriptor.elements.length; i++) {
+          let element = descriptor.elements[i];
+          let arr = typeof element.key === "object" ? privateElements : elements;
+          arr[arr.length] = element;


Both privateElements and elements are undefined.

jridgewell · 2018-08-07T18:42:01Z

PRIVACY_MODEL.md

+        }
+        let result = decorator({...descriptor, elements});
+        for (let i = 0; i < privateElements.length; i++) {
+          result.elements[result.elements.length] = privateElements[i];


This leaks if result.elements is a proxy.

Document privacy model

dcbe00e

As discussed in #136, this is an important missing piece of documentation. cc @allenwb @erights

ljharb reviewed Aug 7, 2018

View reviewed changes

Update PRIVACY_MODEL.md

9d22009

ljharb reviewed Aug 7, 2018

View reviewed changes

s/hidden/inaccessible/

f8e1faf

jridgewell reviewed Aug 7, 2018

View reviewed changes

Fix issues from @jridgewell

fe1d5a3

littledan merged commit cd20a7b into master Aug 8, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Document privacy model #137

Document privacy model #137

littledan commented Aug 7, 2018

ljharb Aug 7, 2018

littledan Aug 7, 2018

ljharb Aug 7, 2018

littledan Aug 7, 2018

ljharb Aug 7, 2018

littledan Aug 7, 2018

ljharb Aug 8, 2018

ljharb Aug 7, 2018

littledan Aug 7, 2018 •

edited

Loading

ljharb Aug 7, 2018

littledan Aug 7, 2018

ljharb Aug 8, 2018

ljharb Aug 7, 2018

littledan Aug 7, 2018

jridgewell Aug 7, 2018

littledan Aug 8, 2018

jridgewell Aug 7, 2018

littledan Aug 8, 2018


		Previous documentation used the term "hard private" to explain the guarantees, but that term may lead some to false conclusions. Here, we use the term hidden, defined as follows:

		> A class element is hidden with the syntax `#name`, which makes it inaccessible except to those granted explicit access to it.

		@@ -0,0 +1,61 @@
		This proposal introduces new metaprogramming concepts on private fields and methods. This document describes the invariants, guarantees and scope of this privacy as a whole, in light of this feature.

		## Private fields and methods are hidden

Document privacy model #137

Document privacy model #137

Conversation

littledan commented Aug 7, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

littledan Aug 7, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

littledan Aug 7, 2018 •

edited

Loading