Suggestion: internal modifier

[mbebenita]

Currently the spec reads: Protected property members can be accessed only within their declaring class and classes derived from their declaring class, and a protected instance property member must be accessed through an instance of the enclosing class.

Relaxing the constraint, "member must be accessed through an instance of the enclosing class" to allow all classes derived from the declaring class as long as they are declared in the same module as the declaring class, would make it possible to have module internal access.

This is closer to how Java implements protected access, rather than C#. Are there plans to add an internal access modifier? If not, then this may be a way to alleviate the pain of encapsulating internal class state.

[danquirk]

Edited the title to make this a suggestion for internal which we have not formally had yet but certainly discussed while considering protected. We don't intend to change protected to mean this but obviously there is a desire for additional accessibility modifiers. Some issues that surface while thinking about this are how to handle merged modules (internal and external).

[AbubakerB]

I was going to raise a suggestion about this, but i found this!
i think its a very important feature.

+1 for the suggestion!

[mreshadi]

I'm not sure if "internal" should be mixed with "protected" etc. But at the very least, it would be very useful to use "internal" instead of "export" for module level definitions so that they could be only accessed by members of the same module in other files.
Basically, module can then act almost like the "assembly" concept in .NET.

[pnewhook]

+1 for the internal modifier. I want to split my code across a few classes, but only a subset should be available to external consumers.

[SergioMorchon]

+1 for internal, specially when biulding reusable code!

[basarat]

Meanwhile "_" is your friend to ease API discovery

[SergioMorchon]

Maybe... but not for linters and SoC: there are already accessor modifiers, so prefixing _ would be redundant, like prefixing string variables strName which already has a type string.

Thanks @basarat

[gautamsi]

+1, I am working on large code base to port from c# and it would leak many methods to consuming code outside of my module.
may I suggest few options (for internal and external modules):

• use tsconfig.josn list of files to allow use of internal modifiers
• add a section in tsconfig.json to list those files. they can use each others internal modifier
• use ///<reference like section with wildcard relative path on top of file which is declaring internal modifier, if wildcard matches the file you are working, you can use internal modifiers.

it may also be possible to ignore this during compilation and consider internal as public, but in generating definition file skip them.

[jezzgoodwin]

I have been working in typescript for a few months now, creating many modules and classes.

This is one of my most desired features.

+1

[benliddicott]

Related, #3854.

Really I think there is a basic problem with trying to be too "pure OO" with access modifiers. This is JavaScript! Any access modifier is ultimately going to be advisory since people can use the [] escape hatch to access your private members if they want to. And they will, just as soon as they encounter a use-case not covered by your class hierarchy.

Modifiers protected and private should not be treated like a chain and padlock, but as a sign saying "Danger - Qualified Personnel Only".

[SergioMorchon]

@benliddicott Yes, we know... But as TypeScript programmer (not JavaScript), it would be great.

It is known that it generates plain ECMAScript, and consumers will be able to hack it. But this is not the TypeScript purpose (obfuscate, protect etc.), but maintain readability and increase productivity.
Bytecode, MSIL, all of them are vulnerable even making "private" or "protected" or "internal" (etc.), becasue of i.e. reflection, perfecty legal!.

I think that that is not the point of view.

[m10s]

+1 for internal

[apastuhov]

+1

[rbuckton]

My take on internal is that it should have the following behavior:

• Available only on a class declaration/expression (for now)
• A member may be marked with only one of public, protected, internal, or private (no protected internal, at least for now)
• Members marked internal in a Source File are treated as public to any other Source File or Declaration File within a Program
• Members marked internal in a Declaration File are treated as public to any other Declaration File (for use with sub-types across multiple declaration files) and private to any Source File within a Program

We would want to emit any internal members of a class out to a respective declaration file in the same way that we emit a private member. This would be used to prevent collisions in subclasses where the superclass is defined in a declaration file.

I'm not suggesting mixing internal with export at this time. For external modules, you can approximate this by just not exporting any internal API from the main module of your package. It may be useful to discuss supporting export internal for namespaces, however, as there's no other way to exclude these types.

[SergioMorchon]

@rbuckton looks nice :) thank you!

[mhegazy]

closing in favor of #5228