Re: Jan 18 meeting notes

+1 for the returned class ... also if we distinguish between "array" and "Array" then the new Boolean/Number/String case can be covered via "Number", if object, rather than "number", which is cool. Th only weird thing would be "object" rather than "Object", as if its [[class]] is unknown br On F

Re: Does private(expr) create a private storage block?

On Fri, Jan 20, 2012 at 2:24 AM, Herby Vojčík wrote: > > Let the object created is foo. When calling foo.method(), it is accessing > private(foo), not private(objectWithPrivates), since this is foo. "If yes" > does not happen. Errors may happen since foo probably does not have private > space (my

Re: January 19 meeting notes

On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eich wrote: > > Yes kids, this means we are going with MarkM's lambda desugaring from: > > https://mail.mozilla.org/pipermail/es-discuss/2008-October/007819.html Is there a version of this desugaring that deals with recursive bindings in the initializer e

Re: January 19 meeting notes

> The downside, if it is a downside, is that if you take a literal C/C++ point > of view, and change > > let a = []; > for (let i = 0; i < 10; i++) { > a.push(function () { return i; }); > } > for (let j in a) { > assert(a[j]() === j); > } > > into > > let a = []; > { > let i = 0; > for (; i <

Re: January 19 meeting notes

On Thu, Jan 19, 2012 at 8:20 PM, Axel Rauschmayer wrote: > Given that this desugaring will only kick in if a closure leaves the loop > (right?), this is a case of automatically doing the right thing (and only if > it’s warranted). > > Yes kids, this means we are going with MarkM's lambda desugarin

Re: January 19 meeting notes

Axel Rauschmayer January 19, 2012 8:20 PM Given that this desugaring will only kick in if a closure leaves the loop (right?), this is a case of automatically doing the right thing (and only if it’s warranted). Right, it's not observable without a closure. The downsid

Re: January 19 meeting notes

2012/1/19 Kevin Reid > On Jan 19, 2012, at 19:40, Waldemar Horwat wrote: > > > Waldemar: What about read-eval-print loops? > > MarkM: Each eval inserts one more nested scope. > This is not what users of REPL want or expect. > > Waldemar: What if someone does this: > > > let x = 3; > > > fun

Re: Jan 18 meeting notes

> So Object.type is the thing to draft. Probably it should return typeof-like > strings with the "null" fix and only that. I do not believe it should start > returning "array" for Array instances, or take other experimental risks. But > we should discuss. FWIW: I’ve written down all typeof use

Re: January 19 meeting notes

Given that this desugaring will only kick in if a closure leaves the loop (right?), this is a case of automatically doing the right thing (and only if it’s warranted). > Yes kids, this means we are going with MarkM's lambda desugaring from: > > https://mail.mozilla.org/pipermail/es-discuss/2008

Re: January 19 meeting notes

Waldemar Horwat January 19, 2012 4:40 PM Discussion about scope of for-bindings. for (var x = ...;;) {...} will, of course, retain ES1 semantics. for (let x = ...;;) {...} Allen: This will behave as in C++: x is bound once in a new scope immediately surrounding just

Re: Does private(expr) create a private storage block?

I can answer how I understood, but I am not the proposer... Andrea Giammarchi wrote: 1. what's the expected behavior with mixins ( borrowed method from different classes ) ? Each class has its own private scope, that is, private in borrowed method is in different "plane of existence"

Re: January 19 meeting notes

On Jan 19, 2012, at 19:40, Waldemar Horwat wrote: > Waldemar: What about read-eval-print loops? > MarkM: Each eval inserts one more nested scope. > Waldemar: What if someone does this: > > let x = 3; > > function foo() {return x;} > > let x = 7; > This would leave foo returning 3. > MarkM: Tha

Re: Block lambda is cool, its syntax isn't

Playing devil’s advocate: The main benefit of having a function shorthand in addition to block lambdas is that minimizers profit from it, right? For the use case that you showed, I wouldn’t mind at all to type the slightly longer "function". I most mind function expressions as parameters (for, s

Re: Jan 18 meeting notes

give typeof its role and leave Array.isArray, Object.isObject, Function.isFunction ... Whaveter.isWhatever it's easy to implement logic :-) For classes it's fine to me to keep using the {}.toString.call(something).slice(8, -1) trick ( Rhino engine as exception but ... they can align with "[object

January 19 meeting notes

Second day meeting notes. Revisited octal/binary constants. Waldemar: Note that we currenty allow both upper and lower cases for a, b, c, d, e, f in hex literals as well as e in exponents and x in hex literals. Breaking symmetry by forbidding upper case for b and o to avoid lookalikes would be "n

Re: Does private(expr) create a private storage block?

as a reference could replace "this" for privates and would make even reading code easier ... private(this) as concept is OK but in practice is misleading quite a lot ( looks an invoke unrelated with "unique" current object as argument ) +1 then for private.whatever On Fri, Jan 20, 2012 at 1:29 AM

Re: Does private(expr) create a private storage block?

Andrea Giammarchi wrote: On Fri, Jan 20, 2012 at 1:05 AM, Herby Vojčík mailto:he...@mailbox.sk>> wrote: P.S.: I posted another thread with proposal for shortcut for private(this), but it still did not reach the list (I see private(this) as non-elegant, too). -1 to private(this) he

Re: Jan 18 meeting notes

Andrea Giammarchi January 19, 2012 4:10 PM for all WeakMap shims and examples I have seen this to guard the key as object is basically: Object.isObject = function isObject() { return Object(value) === value; }; why such difference with indeed function amb

Re: Does private(expr) create a private storage block?

On Fri, Jan 20, 2012 at 1:05 AM, Herby Vojčík wrote: > > P.S.: I posted another thread with proposal for shortcut for > private(this), but it still did not reach the list (I see private(this) as > non-elegant, too). > -1 to private(this) here too ... but specs are outdated so maybe it's already

Re: Jan 18 meeting notes

for all WeakMap shims and examples I have seen this to guard the key as object is basically: Object.isObject = function isObject() { return Object(value) === value; }; why such difference with indeed function ambiguity with your first example? Agreed on Object.type since it's easy to monkey pa

Re: Does private(expr) create a private storage block?

Mark S. Miller wrote: For const classes specifically, my intention is that the "private state" object is "sealed", i.e., it is non-extensible and all its properties are non-configurable, but generally writable unless declared otherwise. Ok, so I present the concerns and then the proposed soluti

Re: Does private(expr) create a private storage block?

Please read the disclaimers: the private(this) syntax is not going to be adopted, ever; private name objects and freeze details have been worked out separately; the classes proposal is out of date. /be ___ es-discuss mailing list es-discuss@mozilla.o

Re: Does private(expr) create a private storage block?

I think private specs are a bit weak right now ... or maybe I did not get them properly ... 1. what's the expected behavior with mixins ( borrowed method from different classes ) ? 2. what if Object.create(objectWithPrivates, descriptor) ? would descriptor methods be able to invoke obj

Re: Jan 18 meeting notes

David Bruant January 19, 2012 1:43 AM Every time I've been thinking of an issue like this, the solution I've found was "whoever runs first wins". This is not relevant to the example I showed. We have a de-facto standard with SpiderMonkey that protects an object fro

Re: Jan 18 meeting notes

David Bruant January 19, 2012 1:15 AM Le 19/01/2012 02:27, Waldemar Horwat a écrit : Brendan: Kill typeof null. Replace it with Ojbect.isObject? What would be the semantics of this? It was not obvious but the precedent stems from the strawman that led to my propos

Re: Does private(expr) create a private storage block?

Mark S. Miller January 19, 2012 2:38 PM For const classes specifically, my intention is that the "private state" object is "sealed", i.e., it is non-extensible and all its properties are non-configurable, but generally writable unless declared otherwise. Hi Mark,

Re: Block lambda is cool, its syntax isn't

François REMY January 19, 2012 12:19 PM It may be just a personnal taste, but I've to agree the current proposal (#() ...) seems very appealing to me. I did not respond to your mail proposing to use the Arrow syntax because it seems obscure to me. The distinct

Re: Block lambda is cool, its syntax isn't

Now you are forgetting the argument that TCP-conforming block-lambdas *should* look quite different from ...(params) {body} functions. This implies that shorter function syntax ought to follow the (params) {body} plan. /be Herby Vojčík January 19, 2012 11:40 AM Bren

Re: Does private(expr) create a private storage block?

On Thu, Jan 19, 2012 at 1:00 PM, Herby Vojčík wrote: > Hello, > > Mark S. Miller wrote: > >> ... I don't have strong feelings about this for non-const >> >> classes. For const classes, I think privates should always be declared >> in the constructor. I would like to be able to always allocate ins

Re: Block lambda is cool, its syntax isn't

Yet they are cases where a block lambda isn’t suited and where a ‘classic’ function is just too long to type (and would hurt performance as well). Look back in the thread for a sample. (Mainly: cases involving a ‘return’ in a loop or in a nested statement can’t be solved well using block-lambda)

Re: Block lambda is cool, its syntax isn't

FTR: With block lambdas and object literal extensions, I wouldn’t want/need a function shorthand. I thought I had seen an opportunity for a more compact syntax (if and only if function shorthands are needed), but was wrong. Sorry. Suggestion: a community-edited page where we collect the rejected

Re: Does private(expr) create a private storage block?

Hello, Mark S. Miller wrote: ... I don't have strong feelings about this for non-const classes. For const classes, I think privates should always be declared in the constructor. I would like to be able to always allocate instances of const classes of fixed "shape", i.e., non-configurable / non-e

Re: Block lambda is cool, its syntax isn't

It may be just a personnal taste, but I've to agree the current proposal (#() ...) seems very appealing to me. I did not respond to your mail proposing to use the Arrow syntax because it seems obscure to me. The distinction between "normal" and "fat" arrow is thin, does not make sense. You eith

Re: Block lambda is cool, its syntax isn't

Brendan Eich wrote: Axel Rauschmayer January 19, 2012 9:31 AM Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you want anything else, you can use a traditional function. Then the above syntax as the only function shorthand would be OK. First, #(

Re: Block lambda is cool, its syntax isn't

Axel Rauschmayer January 19, 2012 9:31 AM Rationale: wouldn’t freezing by default be OK for 98% of the cases? If you want anything else, you can use a traditional function. Then the above syntax as the only function shorthand would be OK. First, #(params) { body } w

Re: A different semantics for WeakMap#get default value

On Thu, Jan 19, 2012 at 12:51 AM, Mark S. Miller wrote: > Hi Jason, I like the idea that the Python defaultdict seems almost to be, > which I'll call an InfiniteMap. For JS, the following InfiniteMap actually > obeys the Map contract while implementing a Map with an infinite number of > key-value

Re: Block lambda is cool, its syntax isn't

Andreas Rossberg wrote: On 19 January 2012 18:31, Axel Rauschmayer wrote: Rationale: wouldn’t freezing by default be OK for 98% of the cases? Especially since the cases where you care most about short syntax are throw-away functions. The only sane reason I have seen for mutating a function i

Re: Block lambda is cool, its syntax isn't

On 19 January 2012 18:31, Axel Rauschmayer wrote: > Rationale: wouldn’t freezing by default be OK for 98% of the cases? Especially since the cases where you care most about short syntax are throw-away functions. The only sane reason I have seen for mutating a function is to set its prototype pro

Re: Globalisation feedback

But time zones other than UTC and the "host environment's current time zone" are not supported. This limitation exists in version 1 of the API spec because one implementation currently doesn't support other time zones. We hope that in the next version this limitation can be removed and all IANA

Re: Block lambda is cool, its syntax isn't

>> Couldn’t one always freeze such a function shorthand and then get syntax >> such as: >> >> #(x, y) { x + y } > > I'm not sure what you mean. I proposed this a while ago ("Harmony of My > Dreams") but we don't want frozen by design, and without the # the result is > ambiguous without res

Re: A different semantics for WeakMap#get default value

I will try to write a complete proposal and settle it at the March meeting. I'll propose today that this be on the March agenda. I'll keep it extremely small. On Thu, Jan 19, 2012 at 5:36 AM, Andreas Rossberg wrote: > On 19 January 2012 09:00, Andrea Giammarchi > wrote: > > Out of curiosity, Chr

Re: Block lambda is cool, its syntax isn't

Axel Rauschmayer January 19, 2012 12:06 AM Couldn’t one always freeze such a function shorthand and then get syntax such as: #(x, y) { x + y } I'm not sure what you mean. I proposed this a while ago ("Harmony of My Dreams") but we don't want frozen by design,

Re: A different semantics for WeakMap#get default value

On Thu, Jan 19, 2012 at 12:44 AM, Andreas Rossberg wrote: > On 19 January 2012 07:51, Mark S. Miller wrote: > > > > Because an instance of InfiniteMap conforms to the full Map contract > (given > > that baseMap does and is not otherwise used), we have full Liskov > > substitutability -- you can v

Re: A different semantics for WeakMap#get default value

On Thu, Jan 19, 2012 at 6:11 PM, Mark S. Miller wrote: > > > That's not quite true in the collection I posted, since an InfiniteMap is > only *initially* total. It still emulates deletes by using tombstones to > poke holes into its initially universal domain. When doing a get at a > deleted key, t

Re: Jan 18 meeting notes

Herby Vojčík January 19, 2012 6:32 AM What about obj.{ ... } literal extension? It is not mentioned, and afaict is unproblematic, too. Thanks, we did miss that one -- it was among the object literal extensions not at the top level of harmony:proposals. /be ___

Re: A different semantics for WeakMap#get default value

On Thu, Jan 19, 2012 at 12:00 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > On Thu, Jan 19, 2012 at 7:51 AM, Mark S. Miller wrote: > >> >> Everyone on this thread, is there any need expressed in this thread that >> is not satisfied by InfiniteMap? >> >> > > I would say for "notific

Re: A different semantics for WeakMap#get default value

On Wed, Jan 18, 2012 at 11:37 PM, Andreas Rossberg wrote: > On 19 January 2012 07:51, Mark S. Miller wrote: > > Everyone on this thread, is there any need expressed in this thread that > is > > not satisfied by InfiniteMap? > > Looks good, except that I don't understand why you want a lazyFactory

Re: Globalisation feedback

We do support UTC and local timezone (whatever it may be). The actual representation of the time zone will differ among platforms (GMT-7, Los Angeles/Pacific...). 18. јануар 2012. 22.16, Oliver Hunt је написао/ла: > Unfortunately I'm not feeling well so I doubt I'll make tomorrows meeting. > > H

Re: Jan 18 meeting notes

Waldemar Horwat wrote: Which ES6 features can be backported into non-strict mode? (blank: no significant issues; ?: possible issues; x: semantics conflict with de facto web) ? let (syntax issues) x const (divergent semantics) x function in block (divergent semantics) ? destructuring (syn

Re: A different semantics for WeakMap#get default value

On 19 January 2012 09:00, Andrea Giammarchi wrote: > Out of curiosity, Chrome experimental flag does not support get(key, > defaultValue) but get(key) only ... is this something missing or Map and > WeakMap will never support officially the second get() argument? Chrome/V8 simply implements what

Re: Jan 18 meeting notes

Le 19/01/2012 02:27, Waldemar Horwat a écrit : Waldemar: Opposed to making __proto__ mutate prototypes other than at object construction. This is getting insanely complex. Just found a minute ago [1]. At line 50, __proto__ is used. Here, the notion of "object construction" is subtle (which is p

Re: Jan 18 meeting notes

Le 19/01/2012 06:44, Brendan Eich a écrit : Use __proto__ in object literals to do a put (assuming that a __proto__ getter/setter was created in Object.prototype) instead of a defineProperty? All modes or only nonstrict mode? Allen: Make such use of __proto__ to be a synonym for <|. If a <| is

Re: Jan 18 meeting notes

Le 19/01/2012 02:27, Waldemar Horwat a écrit : Brendan: Kill typeof null. Replace it with Ojbect.isObject? What would be the semantics of this? -- Object.isObject(null); // false Object.isObject({}); // true // so far so good :-) Object.isObject(function(){}) // ? -- I'd like to advocat

Re: A different semantics for WeakMap#get default value

On 19 January 2012 07:51, Mark S. Miller wrote: > > Because an instance of InfiniteMap conforms to the full Map contract (given > that baseMap does and is not otherwise used), we have full Liskov > substitutability -- you can validly pass an InfiniteMap to an abstraction > expecting a Map. PS: Wo

Re: ES6 doesn't need opt-in

2012/1/10 Herby Vojčík : > P.S.: I would bet 99% of developers thinks the model is in fact "fallback > delegation". :-/ It is simpler model that works most of the time. Always > write locally, always read locally and then look up the prototype chain. I think that's a question of making a fallacy o

Re: Block lambda is cool, its syntax isn't

On Jan 19, 2012, at 8:27 , Brendan Eich wrote: > To fix (2), how about reviving arrows and avoiding the non-LR(1) parsing for > grammar validation problem? Couldn’t one always freeze such a function shorthand and then get syntax such as: #(x, y) { x + y } -- Dr. Axel Rauschmayer a...@ra

Re: A different semantics for WeakMap#get default value

On Thu, Jan 19, 2012 at 7:51 AM, Mark S. Miller wrote: > > Everyone on this thread, is there any need expressed in this thread that > is not satisfied by InfiniteMap? > > I would say for "notification purpose" result = lazyFactory(key, defaultValue); would be more appropriate otherwise the def