I've actually found this limit in the past [1] mostly for string operations
and I remember it was already discussed in here.
2048 was a safe bet for all browsers I could test those days, but it'b be
very nice if any generic function, accordingly with the environment
capabilities, could expose
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
On Wed, Apr 29, 2015 at 6:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The another test that you propose seems to be exactly the fix which
Brandon proposed and I codified, to wit:
2. If IsPromise(x) is true,
a. Let constructor be the value of SpeciesConstructor(x, %Promise%)
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
Just to close the loop on this, regarding the main point I remain convinced
and would be happy to champion. Again, thanks for pushing on this.
More later
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
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
Does http://wiki.ecmascript.org/doku.php?id=strawman:value_objects still
in progress?
What's the relationship between this spec to
http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects
I've heard that ES7 would support for 64bit integer
http://www.slideshare.net/BrendanEich/fluent15
And I
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
When is the estimated time of implantation on import and vice versa.
I know this make no sense to talk on, but I can't wait for the feature so I can
use it in Firefox scratchpad!
Require is nice, but it's not native!
L4L
___
es-discuss mailing list
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
22 matches
Mail list logo
