Update README.md #332
Open
Update README.md #332
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iwikal
reviewed
Jul 28, 2022
|
|
||
| ## Will developers be familiar with this new concept? | ||
|
|
||
| Record & Tuple is built to interoperate with objects and arrays well: you can read them exactly the same way as you would do with objects and arrays. The main change lies in the deep immutability and the comparison by value instead of identity. | ||
|
|
||
| Developers used to manipulating objects in an immutable manner (such as transforming pieces of Redux state) will be able to continue to do the same manipulations they used to do on objects and arrays, this time, with more guarantees. | ||
| Developers used to manipulate objects in an immutable manner (such as transforming pieces of Redux state) will be able to continue to do the same manipulations they used to do on objects and arrays, this time, with more guarantees. |
There was a problem hiding this comment.
No, it was correct before, if perhaps a bit terse.
Suggested change
| Developers used to manipulate objects in an immutable manner (such as transforming pieces of Redux state) will be able to continue to do the same manipulations they used to do on objects and arrays, this time, with more guarantees. | |
| Developers who are used to manipulating objects in an immutable manner (such as transforming pieces of Redux state) will be able to continue to do the same manipulations they used to do on objects and arrays, but now with more guarantees. |
| @@ -760,7 +759,7 @@ We've talked with the Readonly Collections champions, and both groups agree that | |||
|
|
|||
| Neither one is a subset of the other in terms of functionality. At best, they are parallel, just like each proposal is parallel to other collection types in the language. | |||
|
|
|||
| So, the two champion groups have resolved to ensure that the proposals are in parallel *with respect to each other*. For example, this proposal adds a new `Tuple.prototype.withReversed` method. The idea would be to check, during the design process, if this signature would also make sense for read-only Arrays (if those exist): we extracted these new methods to the [Change Array by copy](https://github.com/tc39/proposal-change-array-by-copy/) proposal, so that we can discuss an API which builds a consistent, shared mental model. | |||
| So, the two champion groups have resolved to ensure that the proposals are in parallel *with respect to each other*. For example, this proposal adds a new `Tuple.prototype.withReversed` method. The idea would be to check whether this signature also makes sense for read-only arrays (if those exists) during the design process: we extracted these new methods to the [Change Array by copy](https://github.com/tc39/proposal-change-array-by-copy/) proposal so that we can discuss an API for building a consistent, shared mental model. | |||
There was a problem hiding this comment.
When "during the design process" is immediately attached to the initial clause, it is less ambiguous that it means the idea was to check during the design process, not to check whether it makes sense during the design process. Also, I wouldn't say the API is for building a consistent, shared mental model. The API is for building arrays by copying from another. But a secondary goal is for the two APIs to build a consistent, shared mental model with respect to each other.
| @@ -56,14 +56,14 @@ Records and Tuples aim to be usable and understood with external typesystem supe | |||
|
|
|||
| Today, userland libraries implement similar concepts, such as [Immutable.js](https://immutable-js.github.io/immutable-js/). Also [a previous proposal](https://github.com/sebmarkbage/ecmascript-immutable-data-structures) has been attempted but abandoned because of the complexity of the proposal and lack of sufficient use cases. | |||
|
|
|||
| This new proposal is still inspired by this previous proposal but introduces some significant changes: Record and Tuples are now deeply immutable. This property is fundamentally based on the observation that, in large projects, the risk of mixing immutable and mutable data structures grows as the amount of data being stored and passed around grows as well so you'll be more likely handling large record & tuple structures. This can introduce hard-to-find bugs. | |||
| This new proposal is still inspired by this previous proposal but introduces some significant changes: Record and Tuples are now deeply immutable. This property is fundamentally based on the observation that, in large projects, the risk of mixing immutable and mutable data structures grows as the amount of data being stored and passed around grows as well, so you'll be more likely to handle large records & tuple structures. This can introduce hard-to-find bugs. | |||
There was a problem hiding this comment.
"record & tuple structures" reads like "record-and-tuple structures", meaning structures made from tuples and records, but "records & tuple structures" sounds like it means "tuple structures and records", which is not what we're trying to say.
| - Because they're accessed through typical object and array idioms, no additional branching is needed in order to write a generic library that consumes both immutable and JS objects; with user libraries, method calls may be needed just in the immutable case. | ||
| - We avoid cases where developers may expensively convert between regular JS objects and immutable structures, by making it easier to just always use the immutable ones. | ||
| - Records and Tuples are easily introspectable in a debugger, while library-provided immutable types are often hard to inspect as you have to inspect through data structure details. | ||
| - Because they are accessed through a typical object and array idioms, no additional branching is needed in order to write a generic library that consumes both immutable and JS objects; with user libraries, method calls may be needed just in the immutable case. |
There was a problem hiding this comment.
Remove "a". They're accessed "through [...] idioms". I'm also not sure expanding "they're" to "they are" makes it any more readable.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi, I fix a few grammatical errors and word spellings. Also, I revise some sentences to make them clearer and easy to read for people. I hope these changes will contribute to this project!