Re: typed objects and value types

Note that "value object" proposal does _not_ address int64. On Tue, Apr 8, 2014 at 1:27 AM, Waldemar Horwat wrote: > On 04/02/2014 07:32 AM, Niko Matsakis wrote: > >> I just wanted to let people on es-discuss know about two of my recent >> blog posts concerning typed objects. The first is a kin

Re: setPrototypeOf vs obj.__proto__ assignment

just for topic and documentation sake ... On Mon, Apr 7, 2014 at 11:02 AM, John Barton wrote: > > on platforms without setPrototypeOf(), it's advantages are not relevant. > jjb > > this works in Firefox since quite a while, and probably some other engine that supports `__proto__` as non poisone

Re: typed objects and value types

On 04/02/2014 07:32 AM, Niko Matsakis wrote: I just wanted to let people on es-discuss know about two of my recent blog posts concerning typed objects. The first is a kind of status report: http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/ and the second detai

Re: Rewinding iterators

It would be worthwhile to state that iterators returned by 'built-in' functions always have the "no zombies" property (once done, stays done), even though that can't be enforced on user-supplied iterators. "Be generous in what you accept, rigorous in what you emit." --scott On Mon, Apr 7, 2014 at

Re: Rewinding iterators

On Apr 7, 2014, at 12:06 PM, Marcus Stade wrote: > Thanks Allen! When reading the issue, I can't quite make out what the > reasoning is for setting this constraint on the iterator protocol. Locking > down the behavior of Map/Set/Array iterators is fine I suppose (although I'd > argue against t

Re: Rewinding iterators

Thanks Allen! When reading the issue, I can't quite make out what the reasoning is for setting this constraint on the iterator protocol. Locking down the behavior of Map/Set/Array iterators is fine I suppose (although I'd argue against the permanently closed behavior) but I reckon it seems a bit ov

Re: setPrototypeOf vs obj.__proto__ assignment

that's why it's the preferred choice ... otherwise we keep promoting and trapping developers behind a broken pattern. If we keep saying "just use `__proto__`" code won't ever migrate but it's been discussed that in some case `__proto__` is a very problematic keyword. [nashorn](http://openjdk.java

Re: setPrototypeOf vs obj.__proto__ assignment

On Mon, Apr 7, 2014 at 10:51 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > .. > > It feels like everyone uses `__proto__` on daily basis while ES6 promotes > classes ... so either `__proto__` is not a real world use case, or `class` > landed for no reason, IMO. > You are correct,

Re: setPrototypeOf vs obj.__proto__ assignment

nope, if you have a dict and you use __proto__ nothing should happen, that's why Object.setPrototypeOf is suggested: it's more powerful + it does not show up in getOwnPropertyNames as '__proto__' does so it's shenanigans and errors prone. __proto__ is not even more elegant than Object.create(null)

Re: setPrototypeOf vs obj.__proto__ assignment

Is my understanding correct that __proto__/setPrototypeOf are still required if you want to do things like that with instances of Function? Or did Function's constructor finally get patched to let you set a prototype? On Mon, Apr 7, 2014 at 2:26 AM, David Bruant wrote: > Le 07/04/2014 11:05, Andr

Re: setPrototypeOf vs obj.__proto__ assignment

The context for my question was Tom van Cutsem's excellent Proxy shim, https://github.com/tvcutsem/harmony-reflect, which uses __proto__ assignment to shim Object.setPrototypeOf. In developing Proxy code, objects and not classes are relevant. Directly manipulating the __proto__ is vastly superior

Re: Rewinding iterators

see https://bugs.ecmascript.org/show_bug.cgi?id=2003 which was the original issue that motivated the currently spec'ed behavior. On Apr 7, 2014, at 3:30 AM, Marcus Stade wrote: > Thanks for filing that! Now I also know where to file bugs, so doubly thanks! > > -- Marcus > > > On Mon, A

Re: Rewinding iterators

Thanks for filing that! Now I also know where to file bugs, so doubly thanks! -- Marcus On Mon, Apr 7, 2014 at 10:00 AM, David Bruant wrote: > Le 07/04/2014 02:31, Marcus Stade a écrit : > > In section 25.1.2 of the > spec

Re: setPrototypeOf vs obj.__proto__ assignment

I like __proto__ in object literals, as a nicer Object.create(). In that case, __proto__ is “the new <| operator” and really quite different from __proto__ as a getter and a setter. I have two uses for it: – Dict pattern { __proto__: null, ... } – To explain prototype chains to beginners (=> no

Re: setPrototypeOf vs obj.__proto__ assignment

Le 07/04/2014 11:05, Andreas Rossberg a écrit : On 4 April 2014 19:49, Allen Wirfs-Brock wrote: __proto__ is there for legacy compatibility. setPrototypeOf should be preferred for new code For new code, neither should be used. yup. For new code, in most practical cases, people can use class&

Re: setPrototypeOf vs obj.__proto__ assignment

On 4 April 2014 19:49, Allen Wirfs-Brock wrote: > __proto__ is there for legacy compatibility. > setPrototypeOf should be preferred for new code For new code, neither should be used. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://m

Re: Rewinding iterators

Le 07/04/2014 02:31, Marcus Stade a écrit : In section 25.1.2 of the spec it says: The function returns an object that conforms to the It