On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows isiahmead...@gmail.com
wrote:
On Feb 23, 2015 6:06 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband
Mark: I also agree that `Object.freeze` is flawed, and I welcome a proper
proposal for `Object.tamperProof` or what have you. But `Object.freeze`
works just well enough in the short term that people can build useful
mechanisms on top of it.
My proposal just makes `Map`/`Set` behave consistently
I really like this - I'm writing up a .empty proposal and I'll include
this as part of it, thanks!
On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller erig...@google.com
wrote:
On Mon, Feb 23, 2015 at 11:59 AM, Isiah
This must *not* be hung off of Object.freeze. Object.freeze is about tamper
proofing an object's API, not about making its internal state immutable. I
regret the term freeze for this purpose as it repeatedly suggests this
confusion. OTOH, because of the override mistake, Object.freeze is not
It would also not be compatible with ES6 code. SES will be freezing Map,
Set, WeakMap, and WeakSet instances in order to tamper proof their API. I
expect many others will as well. Having this freeze then cause a
non-mutability in ES7 will break all such ES6 code. This is a non-starter
all around.
Hi Scott, this would only be confusing. Object.tamperProof is built on and
implies Object.freeze. It is like Object.freeze except that it replaces
(some :( ) data properties with accessors in order to work around the
override mistake.
Object.freeze only operates on properties and the
Can you make an alternative proposal that still preserves the essential
property of Object.freeze on collections -- that is to say, preserves
object identity while preventing future writes?
Here's another strawman:
Add [[Immutable]] to the arguments of OrdinaryCreateFromConstructor in
step 2 of
That is indeed the kind of proposal I was looking for, thanks. An issue is
that it locks down the Map in place, which is a design issue we can debate
but is not necessarily a show stopper. I would be happy to see this enter
stage zero to get the conversation started,
Another possibility is to
On Thu, Apr 30, 2015 at 12:46 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
I like the idea of snapshot methods, but they can be implemented in user
code using subclasses in ES6. I'm particularly interested in the lock
down in place mechanism because it *cannot* be implemented in user
It's fine to propose something to make maps immutable. Just don't call it
Object.freeze.
On Thu, Apr 30, 2015 at 11:56 AM -0700, C. Scott Ananian
ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote:
Can you make an alternative proposal that still preserves the essential
property of
It doesn't matter. Others will do the same thing in ES6 and then break
under your proposal in ES7.
On Thu, Apr 30, 2015 at 11:42 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller erig...@google.com
wrote:
It would also not be compatible with
I like the idea of snapshot methods, but they can be implemented in user
code using subclasses in ES6. I'm particularly interested in the lock
down in place mechanism because it *cannot* be implemented in user code.
And yes, if we had it all to do over again, it would have been nice if the
Map
On 4/30/15 3:46 PM, C. Scott Ananian wrote:
I like the idea of snapshot methods, but they can be implemented in user
code using subclasses in ES6.
Can they? You can't create immutable snapshots in user code afaict...
But that would still have required an explicit test in
On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller erig...@google.com wrote:
It would also not be compatible with ES6 code. SES will be freezing Map,
Set, WeakMap, and WeakSet instances in order to tamper proof their API. I
expect many others will as well. Having this freeze then cause a
On 4/30/15 6:20 PM, C. Scott Ananian wrote:
In English -- hide the real Set object so that nobody can get to it to
mutate it.
Sure, but then Set.prototype.has.call() doesn't work on the ReadOnlySet.
That might be OK, depending on how you're using it. But having a
built-in ReadOnlySet would
I don't see how it would be possible in ES6 user code to ever make a
Map/Set or a Map/Set subclass instance immutable, since
`Map.prototype.set.call`/`Set.prototype.add.call` will operate on any
Map/Set-like object's `[[MapData]]`/`[[SetData]]` internal slot. The only
thing I can think of would be
On Thu, Apr 30, 2015 at 5:57 PM, Jordan Harband ljh...@gmail.com wrote:
I don't see how it would be possible in ES6 user code to ever make a
Map/Set or a Map/Set subclass instance immutable, since
`Map.prototype.set.call`/`Set.prototype.add.call` will operate on any
Map/Set-like object's
quick one to whoever will write the proposal: please bear in mind the empty
function **must** have a frozen prototype too
Regards
On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband ljh...@gmail.com wrote:
I'd love to bring a proposal to the committee for this since it seems like
there's
On Feb 23, 2015 6:06 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
quick one to whoever will write the proposal: please bear in mind the
empty function **must** have a frozen prototype too
Regards
Andrea, good catch.
On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband
On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows isiahmead...@gmail.com
wrote:
On Feb 23, 2015 6:06 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband ljh...@gmail.com
wrote:
[...]
- We'd definitely want `Map.empty` and `Set.empty`
On Feb 23, 2015 3:31 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows isiahmead...@gmail.com
wrote:
On Feb 23, 2015 6:06 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband ljh...@gmail.com
Only that the proxy can detect each of the operations as a distinct trap,
and do something weird. A proxy that intend to emulate anything like a
normal object would choose not to, preserving by convention this
equivalence. It becomes a matter of informal unchecked contract
conformance, rather than
I really liked Jordan Harband's suggestion
https://esdiscuss.org/topic/array-prototype-change-was-tostringtag-spoofing-for-null-and-undefined#content-12
of
adding Array.empty, Function.empty, etc. to ES7. It is relatively easy to
polyfill as well.
```js
[Array,
ArrayBuffer,
Int8Array,
I'd love to bring a proposal to the committee for this since it seems like
there's interest.
I suspect that even though some of the empties seem useless to some,
somebody somewhere will find a use case, and consistency is useful (that
everything that could have a concept of empty would have a
24 matches
Mail list logo
