Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should the pragma be named? #3

Open
domenic opened this issue May 3, 2018 · 35 comments
Open

What should the pragma be named? #3

domenic opened this issue May 3, 2018 · 35 comments

Comments

@domenic
Copy link
Member

domenic commented May 3, 2018

I currently have specced "use no Function.prototype.toString".

This might be fine. It's pretty clear on what it does.

Any other suggestions?

@ljharb
Copy link
Member

ljharb commented May 3, 2018

"use native Function.prototype.toString"?

@michaelficarra
Copy link
Member

"delete Function.prototype.toString"

Take it out of quotes for extra umph.

@dead-claudia
Copy link

How about any of these? They don't imply we're dropping or otherwise aliasing Function.prototype.toString, and who says we're bound to the "use ${foo}" format anyways (the spec doesn't)?

  • "censor source strings"
  • "censor sources"
  • "censor as native"
  • "ignore sources"
  • "use no sources" if you prefer to stick with the "use ${foo}" format.

@ExE-Boss
Copy link

ExE-Boss commented Aug 11, 2018

"censor toString" or "use no toString" could also work.

@domenic
Copy link
Member Author

domenic commented Mar 15, 2019

Current spec has been switched (per #17) to "hide implementation". My only concern there is that it might be over-broad, implying e.g. that all public fields will automatically become private fields or something. But, it's pretty good, and I'd be happy keeping it.

@Alhadis
Copy link

Alhadis commented Mar 16, 2019

@domenic What about "hide source"?

@dead-claudia
Copy link

dead-claudia commented Mar 16, 2019

I like that better than any of my previous suggestions. Nice, succinct, direct, and obvious.

(Not TC39, so I have no real power in this. Just a JS dev who likes to observe these discussions.)

Edit: Remove an irrelevant comment.

@ilias-t
Copy link
Member

ilias-t commented Jul 24, 2019

I'd prefer something shorter like "hide source" or "hide code" to "hide implementation", which is more likely to be misspelled.

@michaelficarra
Copy link
Member

Still open to ideas here, but right now we are going with "sensitive", "hide implementation", and (if we must) "preserve implementation".

@Alhadis
Copy link

Alhadis commented Oct 11, 2019

... again, what's wrong with something short and obvious like "hide source"? Honestly, that's all you're really doing.

A function's name and length are technically part of its "implementation", so the word itself isn't entirely correct here. As for "sensitive", that doesn't explain what it's doing, only hinting at secrecy. It could be interpreted any number of ways.

@michaelficarra
Copy link
Member

@Alhadis The function name and position information are also hidden within stack traces by the "hide implementation" directive.

@bathos
Copy link

bathos commented Oct 17, 2019

FYI I would still like feedback on alternative directive names (tc39/ecma262#1739 (comment))

  1. Right now, the directive strings don’t communicate their relationship to one another. I think it should be clearer that the effects of what’s being called ‘sensitive’ are a superset of the effects of what’s being called ‘hide implementation’.
  2. Right now, the directive strings are inconsistent in terms of (English) grammar. ‘Hide implementation’ is an instruction, but ‘sensitive’ is a description. Directives should always be written as instructions IMO, and notably, the only precedent for this is written as an instruction (‘use strict’).* Adjectival naming belongs to the domain of decorators (annotative, declarative) as opposed to directives (interpreter, do something!).
  3. The word ‘implementation’ has an overly broad scope and is often used to mean different things depending on context. I think it should be more clear that it concerns the exposure of source text.
  4. The word ‘sensitive’ has this property also — but even more. Because it does more than one thing, I understand why one might reach for a ‘what it’s intended for’ term instead of a ‘what it does’ term — I assume it’s desirable to keep the strings brief and memorable — but all of the things it does do still concern ‘hiding’ or ‘redacting’. When we combine that fact with (1) above, it hints at an alternative pattern.

I am picturing:

  • "use strict"
  • "redact source"
  • "redact all"

or:

  • "use strict"
  • "hide source"
  • "hide all"

(I have a minor preference for ‘redact’ over ‘hide’. This is probably very subjective — I can explain it, but it’s not as concrete as the considerations listed above. ‘Hiding’ functionality often implies showing functionality also exists; it doesn’t communicate finality the way ‘redact’ does. Redact also helps to communicate that the subject is textual material: these directives concern exposure through strings. Parts of those strings are, at least in terms of apparent effect, spliced out or replaced in order to prevent specific information from being exposed.)

I included "use strict" in these lists to help show how they benefit from following a consistent grammatical pattern / voice.

* re: "use"

Earlier in the thread, it was suggested that the word "use" might be expected to appear. If the goal is consistency, unqualified by context or purpose, any property of ‘'use strict'’ might be a candidate for elevating to a categorical trait (all directive strings end with a consonant!). The goal isn’t consistency, imo — rather, it is communication, and consistency is a tool available in service of that. Communication includes more than recognizability — if possible, a naming pattern should facilitate rationalizability. Users should be able to intuit some sort of story (so to speak) that ties together members of a category regardless of their level of expertise. IMO, in this case it’s the structure and tone of voice, especially when examined in relation to other naming conventions, which provides the highest-value pattern potential — a lil rubric for both recognizing directives and naming directives. For "use" — well, I think the story to tell is not ‘directives tell the interpreter what to use,’ but rather ‘directives tell the interpreter what to do.’ ... ‘[Hey! When you eval this, I want you to] use strict [mode!]’ ... ‘[Hey! When you eval this, I want you to] hide source [text!]’ ... etc. ehh, apologies, this is teetering into weird philosophizing ramble ... lemme slam this inside a <details> ...

@ExE-Boss
Copy link

ExE-Boss commented Oct 17, 2019

I agree, "redact source" should only hide the source reported by function.toString(), but keep function.name and function.length, which are properties present on the instance, and can be removed with the delete keyword.

Also, when it comes to error stack traces, the function name should still be shown.

@devsnek
Copy link
Member

devsnek commented Oct 17, 2019

how about 'hide source' and 'hide calls'

@bathos
Copy link

bathos commented Oct 17, 2019

@ExE-Boss My impression/understanding is that those aspects of the proposal have been resolved (and match what you’ve said).

@devsnek I think those are an improvement, but 'hide calls' fails to communicate that it also hides source.

@Alhadis
Copy link

Alhadis commented Oct 17, 2019

obfuscate works, and it's even shorter than my original suggestion:

"obfuscate";
"hide source";

Bear in mind that even with stack traces involved, hide source is still appropriate because you're essentially hiding the "source" (origin) of a call-site.

@bathos
Copy link

bathos commented Oct 17, 2019

I like the one verb approach, but ‘obfuscate’ has a specific meaning which is not the same as what this directive does. To obfuscate something is not to hide or remove it — it is to make something (which is accessible) too confusing, byzantine, or difficult to understand (that it concerns understandability is essential to its meaning). The term ‘obfuscated code’ is already common and has this other meaning.

@Alhadis
Copy link

Alhadis commented Oct 17, 2019

@bathos Thanks, I had no idea what the word really meant.

@ljharb
Copy link
Member

ljharb commented Oct 18, 2019

What about?:

To hide just the source: ”hide implementation source;” (this hides line/col info from stacks as well, but not the frames themselves)

To hide the function from stack frames: ”hide implementation from stack;” (but toString still works)

To hide from both: ”hide implementation”

Thoughts?

@bathos
Copy link

bathos commented Oct 18, 2019

@ljharb I like those; they’re clear. I would have figured the preference for brevity would be strong among interested folks, but personally, if choosing between something brief but ??? and these, I’d prefer these.

Re: the second item there, my impression was that there was no such directive. Is that wrong / has that changed?

@michaelficarra
Copy link
Member

@bathos You are correct and that is a design change I'm not interested in making. We were pretty thorough in the analysis of the use cases we want to support. We presented this 2-directive solution to committee with general agreement (sans @erights).

@ljharb
Copy link
Member

ljharb commented Oct 18, 2019

I’m not intending to be pushing the design change, more that the pragmas might be more understandable that way.

@hax
Copy link
Member

hax commented Oct 23, 2019

To hide just the source: ”hide implementation source;” (this hides line/col info from stacks as well, but not the frames themselves)

To hide the function from stack frames: ”hide implementation from stack;” (but toString still works)

To hide from both: ”hide implementation”

Thoughts?

I'd like to have shorter and simpler directives like:

'hide source';

'hide stack';

'hide source, stack';

@bathos
Copy link

bathos commented Oct 23, 2019

Those seem pretty reasonable to me too @hax, though I’d be slightly concerned by how easy it is to forget the order ("hide source, stack" vs "hide stack, source"). I’d also point out again that "hide stack" on its lonesome isn’t a thing.

@ljharb
Copy link
Member

ljharb commented Oct 23, 2019

the order is exactly why i made my suggestions quasi-hierarchical.

@hax
Copy link
Member

hax commented Oct 23, 2019

If we really want "hide stack" // toString still work, I think we could allow both order ("hide source, stack" and "hide stack, source").

@devsnek
Copy link
Member

devsnek commented Oct 23, 2019

i don't think a pragma should be considered somewhere to place a list, ordered or otherwise. they are raw strings, they shouldn't contain structured data.

@ljharb
Copy link
Member

ljharb commented Oct 23, 2019

@devsnek i agree; my suggestions were conceptually hierarchical but not structured data.

@hax
Copy link
Member

hax commented Oct 23, 2019

Well, even we don't support list in a single directive string, it could be a list anyway:

'use strict';
'sensitive';
'hide implementation';
...

Any order can work, and 'hide implementation' is redundant but won't cause error (as I understand).

@erights
Copy link

erights commented Oct 25, 2019

"hide source" rather than "hide implementation"

Pun includes the two things hidden: the source text, and where it is from (url and line:column)

@michaelficarra
Copy link
Member

I've changed "hide implementation" to "hide source". Thoughts on changing "sensitive" to "confidential" since confidentiality of its source text and local bindings is the security property we will continuously maintain?

@bathos
Copy link

bathos commented Oct 28, 2019

At first this struck me as an off-kilter word choice due to carrying strong connotations which don’t apply in context (what is confidential is the secrets which have been confided between confidants). However many words need to get repurposed a bit for the sake of loose analogies in programming and this usually happens without trouble. It is an improvement over sensitive .

Although I don’t think confidential is a bad word choice, I do feel strongly that directive* names should continue to actually be directives**. Both "hide source" and "use strict" are directives**, while "confidential" — on its own — is just an adjective.

* The specific thing called a "directive" in ES
** The general meaning in English (i.e., an instruction)

@ljharb
Copy link
Member

ljharb commented Oct 28, 2019

I agree that a directive needs to direct something (transitive verb).

@erights
Copy link

erights commented Nov 27, 2019

Currently, the only operational difference is that "sensitive"; also hides the stack frame. What if we made it do only that and called it "hide frame";? When I think about the reasons I might want to hide sources, vs the reasons I might want to hide frames, I think they're mostly independent.

@rbutera
Copy link

rbutera commented Mar 29, 2022

"private source"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests