As a delegate, I take your opinion seriously. Please try and see how important this could be. I promise I am reading what you say and taking your opinion into account.
var banana = {}
See this variable? Can you tell what type it is?
Then what exactly are you suggesting?
A social convention with TS that causes zero changes to JS which would allow Types to be helpful meta data in variable names for humans.
I'm happy to humor discussing any issues this may cause. If you can give a real world example please do.
Thank you for the question because this is a super confusing subject. Both comments and names can carry completely optional meaning without breaking any JavaScript programs or backwards compatibility.
A social convention isn’t something that TC39 would decide. If you want to use and encourage such a thing, go for it!
Your being horribly unfair to my language choices. Here tear me apart:
TC39 Proposal:
$ - is a new fully optional meta identifier so typescript code can compile to javascript code with types
shoot me. whats the problem? im not suggesting to then make js into ts or change anything.
If you only want a social convention, and not change the ECMAScript language specification, this is probably the wrong discussion forum. But sure, pitch your idea to the TypeScript authors! It would be them who would have to change their compiler code.
Though imo, name mangling is hard to do correct (without introducing conflicts) and would probably break some code (that relies on identifier names, and in particular property names); so I suspect this proposal would be shot down. Personally, I don't have a large need to read transpiled TypeScript code anyway, I can either read the source code or there's a source map accompanying the JS code.
Please give me example code that breaks. I need real world problems!! Your example would require major negligence wouldn't it?!
Is the error once someone does Object Stringify?
For context bergus, there is a Typed Comment proposal in TC39. This is absolutely the place for this discussion - so is TS.
A standard is a social convention. OMG. I promise I am not nuts. I was only trying to say I didn't want to change the JS engine itself. This only requires a actual code change to TS.
Whats the point for me to talk to TS people about types compiling into JS when you all tell me No without any example on hypothetical technical grounds?
This whole thread feels like a misunderstanding :( I am not good at social convention.
I will try and talk to the Type Comment people about Type Names but I am dreading it already.
A social convention isn’t something that TC39 would decide.
This is completely false your saying it backwards. The entire point of a Standard is to create social convention and the entire point of an Identifier is to be valid.
Who here thinks TS doesn't depend on the TC39 standard? The entire point of this thread is to discuss a standard between JS and TS.
This is gas lighting isn't it? My proposal is 1 line of code.
This is working TypeScript:
class Example {
constructor(public property: string) {}
}
const instance = new Example("value");
const value = instance[`${"prop"}${"erty"}`];
console.log(value);
Your suggestion appears to be to transpile this to the following JavaScript:
class Example$typeofExample {
property$string;
constructor(property$string) {
this.property$string = property$string;
}
}
const instance$Example = new Example$typeofExample("value");
const value$string = instance$Example[`${"prop"}${"erty"}`];
console$Console.log(value$string);
This doesn't work any more due to at least two problems.
The ECMAScript standard is a technical specification, describing in utmost detail how to parse and interpret code. It has nothing to do with social conventions.
Sure, there's other coding standards like styleguides that you can choose to follow or not (or create and popularise your own), but those are not discussed in this forum.
Thank you for the detailed example. Is the solution there simply to not apply this rule to properties in classes like that? It's not super clear and your code is doing a lot of weird stuff. It is a great sample of how much we use Names as Types already.
I recommend not "Typing Everything" just for the sake of it like you have shown. It feels like you transpiled the code in the worst way you possibly could when the goal is to find the best way.
Pretend this literally only applies to variables. If your reading the variable name your doing it for a reason so explain the reasoning.
I was thinking about this only for simple variable types like my examples so your perspective is greatly appreciated.
social convention semantics
This kind of detail you just brought up would be great in a standard technical specification on how to safely denote TS types in JS. I am working on making a proposal.
A TC39 JS Typing style guide for TypeScript honestly sounds like a great idea too but as you say we better not use unallowed idea framing.
Is this the error here? This extreme unnatural form of negligence is why this cannot work?
None of these issues appear in JS obviously so it is important to figure out what TS compiler problems I really need to worry about. Ultimately nothing is requiring all old code and new code to do anything.
Pretend 2 things:
- A TC39 Standard Recommendation for storing Types in names with an Identifier as completely optional human readable helpful variable describing name data. (similar to Typed Comments)
- Completely optional build tooling (a TS build option) to compile into the new TC39 format.
This way - no one doing TS Metaprogramming gets suddenly surprised and nothing breaks. The final work then is me implementing the change into TS. Is this idea crazy? Yes. Is it actually simple? Yes I think if we try to make it be!
And properties in objects. And global variables. And exports. And parameter names. And probably a lot of other things that code in the wild depends on.
The names in my example snippet are absolutely meaningless.
No, that's just a very short example of property access with a non-trivial expression that TypeScript still accepts. You can construct your own example with some more dynamic expressions and less weird syntax.
You don't actually need the first thing - I mean you may need a recommendation, but it doesn't have to be an ECMA standard. You can just start building the completely optional build tooling. If you can convince enough people that using this build option is beneficial for them, and it becomes hugely popular, so popular that alternative implementations of the same idea pop up that do things slightly differently, that is when you may need a standard to guarantee interoperability. Although I still fail to see what the possible interoperability issues would be if the names are not supposed to be used programmatically anywhere.
Thanks for the recommendation. If Typed Comments are a valid idea for TC39 I believe Typed Names are too. My Stage 1 proposal could be to ask if JS indeed does need a new Valid Identifier for Types or not.
It frustrates me that in order to make a proposal valid in your eyes I must add new syntax like Typed Comments. However, it should be considered since $ is already a valid identifier. The TC39 proposal should ask if we need new syntax for Types in JS or not? If we do want Types in JS, should it be new Name Type syntax or new Comment Type syntax.
I will do my best to figure out how to frame my Proposal correctly.
Does anyone have any ideas for a good new identifier to add to JS to denote a Type in a variable name?
Right now the valid only options are:
_
A-z
0-9
$...
I wonder what TC39 would consider a good new Identifier to add here for Types. I will brainstorm this.
Lets please restart on fresh footing now and take a bunch of steps back. Maybe we can come up with an even better letter than $ to propose.
Type Identifier to discuss: "."
notes.txt
program.exe
See the name and type? A real life Type Identifier!
We obviously can't use "." as a new Variable Type identifier but see how beautiful and seamless it is since we are used to seeing it our whole lives?
We can propose a new valid identifier even better than this for JS Variable Types. $ is a great backup plan but its obvious how important Types are to programming names and a new valid identifier could be incredible for JS and make a great new standard. The best thing about a new official TC39 JS type identifier is it would essentially add JS type identifiers to JSON too. I think other JS programmers could get excited about this too. The idea isn't that spooky or complicated I promise. Don't let overly complex TS variable name metaprogramming scare you away from a perfectly valid simple JS standard for Types. It's more important to JS than it is to TS which is why TC39 is the place to discuss it. I'm a JS dev and want a standard to use Types in my code and there is nothing wrong with such a proposal.
How would type arguments work:
let m: Map<string, Set<string>>;
becomes m$... ?
m$Map - which makes sense im guessing its the reason why you named it "m".
I think you're in the wrong forum. IIUC, you want tsc to emit type information attached to local variable identifiers. Then head to Issues · microsoft/TypeScript · GitHub. However, I suggest you first peruse TypeScript Design Goals · microsoft/TypeScript Wiki · GitHub, particularly goal 9 and non-goal 5. It kinda sounds like you're going against those.