GeezerVison

Yay!

Just stumbled upon this. Don't think I could be any happier than I am right now.

Anders Hejlsberg (@ahejlsberg) These questions in #8496 (and the issue in general) are highly relevant to the topic here. Consider providing your comments. I have only closed that issue because I felt that your (unbelievably stubborn and righteous) team members would somehow find it more 'respectful' that I show my complete pessimism at having any influence here than trying to 'confront' them in any way. You have already won the 'battle', congratulations, now feel free to join the discussion.

Unbelievably stubborn and righteous, eh?

[I apologize for this being very off-topic but since I was asked I felt I had no choice but answering here, the person who asked doesn't have a public email so there is no way for me to contact them personally]

Joel Day (@joelday)

Yes, my personal impression is that they are very 'difficult' people to deal with, in the sense that they are putting as much energy into 'justifying' (sometimes dishonestly or irrationally) their actions and decisions to actually considering things openly and objectively when presented to them. They even do this on some very trivial subjects (e.g. you tell them they don't conform to the ES6 spec by practically disallowing inheritance of static accessors for ES5 targets and instead of listening and acknowledging the problem like a normal person would do, a group of team members just 'jumps' on you and starts to throw some strange and arbitrary ('canonical') justifications about performance consideration and dubious statistics there is '0%' anyone would ever want to do this.. well I did! and so did others who reported this problem, and probably many who didn't.. :( ).

They put you in a situation where you have to be so eloquent and rational, to the point you have to literally spend dozens of hours into very carefully and rationally crafting a 'thesis' for something otherwise relatively trivial, just for them. And they on the other side are allowed to simply 'push' their opinions and twisted patterns of 'justification' arbitrarily without anyone saying anything. When you start challenging those patterns they would either ignore you or tell you you are intentionally 'wasting their time' with things that aren't important. They would also use their 'internal' understanding of the language and compiler by mentioning intricate things or concepts you don't know or completely understand and dishonestly use that against you.

They take submitted ideas they like but they don't actually partake in real two-way conversations about it. They don't really involve the submitter of their personal ideas and insights, at least before they decide on their actions. And when/if they do inform back, they would condense it to a set of a few sentences that are not very useful or enlightening by themselves (or direct you to a set of design 'notes' that are very hard to extract anything useful from). You can't ask a (non-trivial) question because that's just 'wasting their time' (they don't do 'one on one').

If they don't like an idea, they would usually 'tank' and attack it mercilessly to the point of almost (or perhaps actually) insulting the person who submitted it. They almost never 'improve' on things suggested to them, at least not publicly. They would rather spend their time and 'smarts' in crafting careful arguments for justifying why they think someone are 'wrong' and they must be 'right' than taking a step back to seriously and objectively reconsider things, and eventually thank the participant for contributing something useful to the discussion.

This has been my experience so far, anyway. I'm mostly referring here to the 2-3 members who reply to GitHub issues.

Is there any reason / chance to change that the generated code contains regular property assignment and not defineProperty with writable: false? That would help a lot to protect against runtime assignment to properties designed as readonly.

I agree with Ingvar Stepanyan (@RReverser) - on my team we frequently use TypeScript compiled code from (legacy)JavaScript applications - so keeping as many of those protections as possible would be very helpful.

Is this already available or only for TypeScript 2.0 (neither VS nor TypeScript Playground seem to understand it)

@Aides359 As usual with all the fresh stuff, you need to use npm i typescript@next to get the latest compiler with experimental features included.

@Aides359 I think the playground hosts the latest stable release. I recommend doing what Ingvar Stepanyan (@RReverser) suggests and additionally installing vscode and setting then "typescript.tsdk" property of your user/workspace settings to the install location's lib directory.

Read-only properties may have initializers and may be assigned to in constructors within the same class declaration, but otherwise assignments to read-only properties are disallowed.

Why disallow assignments in the other methods of a class?

A readonly property would be useful to implement a getter with a true property (better for performance, readability):

class Foo {
    readonly a = 1;
    inc() {
        ++this.a;  // Why not allow to do this?
    }
}

Does the limitation exist for a technical reason?

If that were allowed we'd have daily reports about "Bug: Why does TS let me mutate readonly fields?" 😉

We discussed the notion of "public readonly, protected mutable" but opted not to simply due to complexity. You can already have a getter-only wrapper around a private variable, which achieves the same semantics at the cost of slightly increased class size.

OK. You use the term readonly as a synonym for const. I hoped an accessor readonly. :(

I use this great feature for mutable preventing by the syntax highlighting. Thanks a lot for this!

+++

This change isn't as bad as it might sound because we'll always error on direct assignments to readonly properties and that's where the majority of the errors occur.

this is a horrible change, rendering this feature usless

simple use case that fails, I have my app about 1500 TS files thick, in this app I have an interface named Data that was intended to be immutable historically could not be forced being so

With the readonly feature announced it was immediately clear that such enforcment can be imposed.

However it turned out that there were a few places where Data was meant to be mutable.

To address it the original Data interface was split into ReadOnlyData and WitableData, however it didn't help much due to the said decision. Details can bee seen in #13002.

Bottom line is we are still not sure if Data is effectively mutable or not, despite applibg readonly to all its properties.

Anders Hejlsberg (@ahejlsberg) Correct me if I'm wrong, but the only reason interface compatibility checking on readonly is a breaking change is because of readonly being implicitly applied to everything. The tradeoff of worse soundness in return for saving the user some typing, especially when you now have mapped types, is not a good one IMO.