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

Decorator-like syntax suggestion #13

Closed
littledan opened this issue Sep 6, 2018 · 15 comments
Closed

Decorator-like syntax suggestion #13

littledan opened this issue Sep 6, 2018 · 15 comments

Comments

@littledan
Copy link
Member

littledan commented Sep 6, 2018

My main concern with this proposal is the use of the string pragma syntax. One issue is that typos become silent errors, as they are just ignored as comments. I think it'd be nice if we could do this proposal in a way that would work as an extension point for more things, and I'm not sure if we want to go this way with "use strict"-style pragmas.

@rbuckton has proposed @namespace: decorator notation for decorators which do different things. I think we could reserve a namespace for built-in, static things as well. (My understanding is that's what Swift uses @ for, so we wouldn't really be innovating here.) As a straw(person), how about this:

@early: noFunctionPrototypeToString
function foo() { }

The semantics here would be that each function would need to be individually annotated to get censorship; it wouldn't be nested (I can see why this would be a disadvantage).

I think this syntax would work just fine for all the syntactic forms that we care about: function declarations and expressions, class declarations and expressions, concise methods, and arrow functions. AFAICT there's no need for any no-line-terminator-here or any other syntactic hacks; between the @ and the : we're already in pretty free territory.

We could start with this proposal being the one place where the syntax is used, and define other usages over time.

Thoughts?

@domenic
Copy link
Member

domenic commented Sep 6, 2018

The lack of ability to apply to a source file, or cascading in general, seems like a deal-breaker to me. Consider what it would look like to censor everything in a source file: you'd have to do this on all methods, arrow functions that are used as callbacks, accessor bodies, etc.

See also #9, where I captured some of the committee discussion as to why pragmas are the best fit. (Still need to translate that into the readme.)

@littledan
Copy link
Member Author

Among the points in #9, I guess "backwards compatible" is the biggest mismatch? I am curious why direct source backwards compatibility is a goal here rather than trabspilability.

For censoring everything in a source file, I wonder if your original proposal for an out-of-band signal (e.g. HTTP header on the web or parameter in a build system for standard libraries) would be a good idea.

@domenic
Copy link
Member

domenic commented Sep 7, 2018

The out of band signal does not fit the use case presented in this repository, where library authors (who generally only control the source code they distribute) want to preserve encapsulation.

@littledan
Copy link
Member Author

What if we used this syntax, but said that it led to cascading semantics?

@domenic
Copy link
Member

domenic commented Jan 3, 2019

Then it would not be backward-compatible, as discussed upthread...

@littledan
Copy link
Member Author

How strong is the backwards compatibility requirement? It seems like we've been pretty successful in adding new syntax to JavaScript, and people use build systems to convert to the old syntax. This directive is readily transpilable (with a monkey-patched Function.prototype.toString).

@domenic
Copy link
Member

domenic commented Jan 8, 2019

I believe @erights was the one most interested in backward-compatibility here.

Can you explain why you want to break backward compatibility with your new, as-yet-unused-anywhere syntax? It seems like you have a syntax in search of a problem to solve, which seems backward to me.

@littledan
Copy link
Member Author

Well, I'm concerned about explosions of different syntax; I think we can use decorator-like syntax for various different problems that we're trying to solve. I'll post an explainer soon where I explain my concerns with string pragmas and other use cases for decorator-like syntax.

@domenic
Copy link
Member

domenic commented Jan 8, 2019

Hmm, I too am concerned about the explosions of different syntax. As such, using a preexisting syntax instead of introducing a new one (which has some pseudo similarities to decorators, like using the @ sign, but seems otherwise unrelated) is worrying to me.

@littledan
Copy link
Member Author

Right, I think this is a broader question than just this repository. I agree that, if we use this decorator-like syntax just for this one single case, it'd be adding extra complexity that's not really justified. Let's discuss at the next TC39 meeting whether we want to consider using more general decorator-like syntax as a pattern going forward.

@michaelficarra
Copy link
Member

The committee chose to use a directive-based approach for this feature.

@hax
Copy link
Member

hax commented Oct 28, 2019

@michaelficarra Links to related tc39 notes may help others to find the further discussion?

@littledan
Copy link
Member Author

It's fine with me to close this issue, but I remain somewhat skeptical of using a string-based directive, and I don't remember any sort of consensus affirming that we agree on a directive. I think we could call this truly settled once the proposal goes to Stage 3 with a string-based directive.

@michaelficarra
Copy link
Member

@littledan during my most recent presentation of this proposal, I explicitly asked for objections to each of the following decisions:

  • the limitation to the use cases outlined in the presentation
  • a two-directive solution (as opposed to dynamic alternatives presented)
  • a third directive, as requested by @erights, if follow up discussions found that to be necessary

None were raised.

@littledan
Copy link
Member Author

Ah, sorry, I must not have heard well from remote. Probably when the notes are published, the results will be clear. (Did you ask for objections to string-based pragmas?)

(However, note that, in the past, when I asked for objections about various decorators issues, people didn't end up raising them until the proposal to promote it all to Stage 3.)

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

4 participants