-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
|
Take it out of quotes for extra umph. |
How about any of these? They don't imply we're dropping or otherwise aliasing
|
|
Current spec has been switched (per #17) to |
@domenic What about |
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. |
I'd prefer something shorter like "hide source" or "hide code" to "hide implementation", which is more likely to be misspelled. |
Still open to ideas here, but right now we are going with |
... again, what's wrong with something short and obvious like A function's |
@Alhadis The function name and position information are also hidden within stack traces by the |
I am picturing:
or:
(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 |
I agree, Also, when it comes to error stack traces, the function name should still be shown. |
how about |
"obfuscate";
"hide source"; Bear in mind that even with stack traces involved, |
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. |
@bathos Thanks, I had no idea what the word really meant. |
What about?: To hide just the source: To hide the function from stack frames: To hide from both: Thoughts? |
@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? |
I’m not intending to be pushing the design change, more that the pragmas might be more understandable that way. |
I'd like to have shorter and simpler directives like: 'hide source';
'hide stack';
'hide source, stack'; |
Those seem pretty reasonable to me too @hax, though I’d be slightly concerned by how easy it is to forget the order ( |
the order is exactly why i made my suggestions quasi-hierarchical. |
If we really want |
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. |
@devsnek i agree; my suggestions were conceptually hierarchical but not structured data. |
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 source" rather than "hide implementation" Pun includes the two things hidden: the source text, and where it is from (url and line:column) |
I've changed |
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 Although I don’t think * The specific thing called a "directive" in ES |
I agree that a directive needs to direct something (transitive verb). |
Currently, the only operational difference is that |
|
I currently have specced
"use no Function.prototype.toString"
.This might be fine. It's pretty clear on what it does.
Any other suggestions?
The text was updated successfully, but these errors were encountered: