171

Closed

protected keyword

description

I would like to know if the "protected" keyword will be implemented eventually ?
Right now, it doesn't seems to work.

By the way, great job ! I really like TypeScript :D
Closed Jul 28 at 10:17 PM by jonturner
As part of our move to GitHub, we're closing our CodePlex suggestions and asking that people move them to the GitHub issue tracker for further discussion. Some feature requests may already be active on GitHub, so please make sure to look for an existing issue before filing a new one.

You can find our GitHub issue tracker here:
https://github.com/microsoft/typeScript/issues

comments

rwaldron wrote Oct 5, 2012 at 11:41 PM

It was part of the at-name proposal, but has been deferred to ES7 and will have it's own strawman. The proposal begins here http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names#class_protected_name_declarations

LukeH wrote Dec 3, 2012 at 5:29 AM

If added to TypeScript, 'protected' would be similar to TypeScript's current 'private' in that it would not have any runtime manifestation at least when targeting ES3/ES5. That said, we are hesitant to continue to add complexity to the ad-hoc visibility options - especially before seeing what the runtime options that could support these look like in ES6/ES7 plans.

stanthomas wrote Mar 20, 2013 at 9:26 PM

In the short term would be happy to have protected as the equivalent of
#define protected public
i.e.just to signal intent until a more rigorous solution can be implemented as per LukeH's comment.

fixxxerrr wrote Mar 22, 2013 at 9:00 AM

+1 for "#define protected public" and compile-time scope validation

DRubino wrote May 21, 2013 at 4:37 PM

+1 for "#define protected public", even if it's not causal.

But it would be nice to have protected enforced by the compiler, even without runtime ramifications.

billyzkid wrote May 22, 2013 at 11:46 PM

We really need protected keyword support. I find myself constantly doing this:

public / protected / _myProtectedField;

or

public _doSomethingProtected() { ... }

Note I am using the convention of public underscored fields and methods to allow me to flag and access these pseudo-protected members. The underscore reminds me not to use it outside the class, but it would be really nice if the compiler enforced it. No need for actual protection at runtime of course.

This should be trivial to implement, right?

mindplay wrote Sep 13, 2013 at 9:08 PM

Big time +1

I also find myself starting out with private members, and then having to make lots of members public that actually would/should be protected in other languages.

On a related note, I really hope internal gets implemented - in larger, modular libraries, having members that are accessible only to other classes in the same module, would be a huge advantage.

Currently the two most crucial missing features for me in TS...

jamesnw wrote Oct 9, 2013 at 3:43 PM

Yes, I find myself wanting to enforce this at the TS level also (I'm aware that protected may still be accessible regardless if one wanted to, but it all boils down projecting the intended usage).

jamesnw wrote Oct 9, 2013 at 3:45 PM

Just to add: This is a big requirement when writing APIs for end users.

BBGONE wrote Oct 15, 2013 at 7:36 AM

It would be good that protected members (typically starting with underscores) are not shown in intellisence outside of classes. They should not distract end users.

onTouch wrote Dec 13, 2013 at 1:27 PM

The biggest problem I think is, that we have to use public to prevent warnings. but why should i make fields public, when I plan to make them accessible only via getters and setters. I think it's one of the most needed features. Why implement all that stuff when there's such a big hole at the basis of the whole object oriented mechansims of TypeScript?!

adamrogas wrote Feb 6 at 7:35 AM

This is a must have feature, especially if we ever want to produce an optimized output from TSC.exe

bdastous wrote Feb 15 at 6:16 PM

+1 to make life easier for consumers of our classes

grizzly33 wrote Apr 5 at 2:56 PM

this would be quite useful to have..

grizzly33 wrote Apr 5 at 3:07 PM

Btw, what is the hold up here? It actually works already with private accessors, calling super.myMethod() works too, but the compiler error is annoying, all that would be needed is that to go away, if protected is actually not gonna be added.

PatrickMetz wrote Apr 16 at 10:28 AM

+1

Mainly using PHP, but constantely writing frontend code, too, I switched to TypeScript as my frontend Javascript base of choice, to be able to write more strict and more robust object oriented code (And it feels great, by the way. I like TypeScript a lot!).

That being said, I was really surprised that there is no "protected" keyword, as it is a quite fundamental OOP feature.

However, I do understand your decision to postpone this feature, but seriously hope it will be going to be implemented rather sooner than later.

For the time being I'm going to treat public methods and attributes prefixed with an underscore as protected.

Regards,
Patrick

Ciantic wrote Jul 4 at 5:27 PM

+1

Basically, we are waiting for ES-committee to make a decision, just in case their implementation is incompatible with normal behaviour of protected?