Modules using the "export" keyword instead of "public"

Topics: Language Specification
Oct 24, 2012 at 10:29 PM

I realize that the ECMAScript 6 proposal currently uses "export" instead of "public", but does anyone else find this to be problematic? Coming from other languages, I find this inconsistency between class members and module members extremely annoying. 

Perhaps TypeScript could support using "public"/"private" modifiers on classes within modules in addition to the "export" keyword? Other than the cost of implementation, does anyone see any other costs? 

Oct 24, 2012 at 11:59 PM

You can't just be adding ambiguous syntax to languages because they're not like other languages. There is altogether too much of this "make TypeScript more like C#/VB.NET/Smalltalk" nonsense going on round here. It's a superset of ECMAScript with early support for syntax from v6 of that language. It's not a damn free-for-all.

Oct 25, 2012 at 4:59 AM
markrendle wrote:

You can't just be adding ambiguous syntax to languages because they're not like other languages. There is altogether too much of this "make TypeScript more like C#/VB.NET/Smalltalk" nonsense going on round here. It's a superset of ECMAScript with early support for syntax from v6 of that language. It's not a damn free-for-all.

"ambiguous" - not at all ambiguous, as Java, C#, C++ and many other languages use public/private access modifiers for classes. I don't believe TypeScript should be just like C#, but I also don't think it should handicap what features it can and can not have based on a committee over which it has no influence.

"superset" - A superset contains greater than or equal to the number of features of the original language. Saying "this can't be in the language because its not in ECMAScript" is equivalent to saying TypeScript shouldn't exist at all.

In my opinion, the "export" keyword is surprising and non-intuitive. TypeScript already uses public and private modifiers to denote accessibility. Why should it be any different for class accessibility? It's likely the word "export" was chosen by the committee simply because its the dual of "import" (which is used to load modules). This seems like a weak reason to add inconsistency into a language. 

Oct 25, 2012 at 12:49 PM

If the export keyword is used by ECMAScript and TypeScript adds the word public to mean the same thing, then you've got ambiguous syntax and you've changed ECMAScript instead of extending it. There is no difference between what you're suggesting and a VB programmer asking for Dim as an alternative syntax to var.

A superset should not change something which already exists, it should be additive.

TypeScript will gain wider acceptance if it stays close to the ECMAScript syntax. As soon as you start adding in arbitrary changes like the one you propose, you change the entire philosophy of the project and lose all the credibility that TypeScript is working so hard and so well to achieve.

On Oct 24, 2012 11:59 PM, "MgSam" <notifications@codeplex.com> wrote:

From: MgSam

markrendle wrote:

You can't just be adding ambiguous syntax to languages because they're not like other languages. There is altogether too much of this "make TypeScript more like C#/VB.NET/Smalltalk" nonsense going on round here. It's a superset of ECMAScript with early support for syntax from v6 of that language. It's not a damn free-for-all.

"ambiguous" - not at all ambiguous, as Java, C#, C++ and many other languages use public/private access modifiers for classes. I don't believe TypeScript should be just like C#, but I also don't think it should handicap what features it can and can not have based on a committee over which it has no influence.

"superset" - A superset contains greater than or equal to the number of features of the original language. Saying "this can't be in the language because its not in ECMAScript" is equivalent to saying TypeScript shouldn't exist at all.

In my opinion, the "export" keyword is surprising and non-intuitive. TypeScript already uses public and private modifiers to denote accessibility. Why should it be any different for class accessibility? It's likely the word "export" was chosen by the committee simply because its the dual of "import" (which is used to load modules). This seems like a weak reason to add inconsistency into a language.

Read the full discussion online.

To add a post to this discussion, reply to this email (typescript@discussions.codeplex.com)

To start a new discussion for this project, email typescript@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Oct 29, 2012 at 2:34 PM
Edited Oct 29, 2012 at 2:36 PM

Here, here Mark. Well said.

@MgSam: Exports are very frequently paired with the concept of modules in many languages. Public/private belong to class definitions. Exports belong to modules. The are not at all the same thing - if you think modules and classes are the same concept, then you need to think about that some more. The export keyword is _highly_ intuitive.

You complain about your perception of ambiguity, but the greatest irony is that your "fix" would introduce it for real.