Private typescript keyword does not seem to be resolved to appropriate javascript

Topics: Language Specification
Oct 9, 2012 at 2:55 AM

I was watching Ander's video, which was great. But I noticed that when he was talking about the use of the typescript private keyword that the resulting javascript implementation of the variable was using the this keyword. I'm not sure this is right since you can implicitly get privacy by using var instead. Here's a nice link in Crockford's site explaining the details http://www.crockford.com/javascript/private.html. I'm hoping they switch to this output style in the future.

Oct 9, 2012 at 3:17 AM

I hope they don't. The way it's done at the moment is significantly cleaner and requires no inner functions within the constructor just to access a 'private' var.

Oct 9, 2012 at 3:42 AM

It works for var variables without functions, but I see your point.

Oct 9, 2012 at 4:38 AM

@photonstorm - I'm not sure what's cleaner about the current implementation. It's not what many people used to Javascript would expect.

How to implement private isn't a totally obvious design choice, but if private properties are going to be implemented as properties hanging off 'this', I wonder if it wouldn't at least make sense to define them as non-enumerable.

Oct 9, 2012 at 6:07 AM
Edited Oct 9, 2012 at 6:09 AM

The way it does it at the moment is mostly what I'm used to, I just expect an _ in the private var name:

this._x

So I'm a bit biased, but I know what you mean. Has to be a trade-off somewhere I guess, given how there's no real way of implementing privates nicely without upsetting one camp. It's such a significant design choice though that I don't for a moment think they chose it idly or were unaware of the var method (it's just a reason best known to them right now).

Oct 9, 2012 at 7:31 AM
Alexjs wrote:

@photonstorm - I'm not sure what's cleaner about the current implementation. It's not what many people used to Javascript would expect.

How to implement private isn't a totally obvious design choice, but if private properties are going to be implemented as properties hanging off 'this', I wonder if it wouldn't at least make sense to define them as non-enumerable.

In ES5 - probably yes, however is non enumerable make them non-callable?

The thing with the closed-over properties is that it takes too much memory: I personally have seen this in lots of libraries especially ones that want to provide as many functionality as possible into one. Each instance make a closure and often not one. 

The idea in the implementation is that if the method/property is marked as private at compile time calling it from an instance is not allowed. At run time it does not matter really, because 'nice third party' is assumed (i.e. that no one will touch it even if it is exposed in the prototype). Having everything in the prototype saves memory and also one can more easily 'clean up' (see goog.Disposable if you like). TypeScript will not prevent you from implementing the desired pattern in your code, but the javascript spilled as result of the class pattern they selected is the best in regard of memory consumption and this is important as they are targeting large application for the web. 

Oct 9, 2012 at 5:22 PM

Non-enumerable wouldn't make them unusable or uncallable, but it hides them a little better. It has two main effects:

1. If you iterate over the keys of an object using 'for-in', you don't see non-enumerable objects

2. As a result JSON.stringify will not write out the property by default (you can still customize this to write the non-enumerable properties if you need to)

Non-enumerable seems like the right choice for private members to me.

Oct 10, 2012 at 12:14 AM
Edited Oct 10, 2012 at 12:19 AM

Lot's of things have a cost associated to them. Certainly adding classes and modules has a cost (ecmascript 6), even functions have some cost. But I think if we're calling something private it should behave in a private way. I mean after all if people don't like the performance cost you could simply choose not to apply the private keyword right?

Oct 10, 2012 at 7:00 AM

You can say that, yes. Unfortunately lots of JavaScript developers do not understand the cost associated, maybe that is why the decision was made to only use the privacy at compilation level and not in the resulting code. Imagine targeting mobile, while ie6 is soon to be gone everywhere, the new IE is mobile browsers. They tend to be sensitive on memory...

Oct 15, 2012 at 3:00 PM

There is an existing discussion on this, with a note from Anders:

http://typescript.codeplex.com/discussions/397651

Dec 30, 2012 at 6:25 AM

Sohnee I made a response within the post that you linked to. I think my work arounds are reasonable.