On Thu, Jan 19, 2012 at 7:51 AM, Mark S. Miller erig...@google.com 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
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
2012/1/10 Herby Vojčík he...@mailbox.sk:
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
On 19 January 2012 07:51, Mark S. Miller erig...@google.com 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
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
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
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
On Wed, Jan 18, 2012 at 11:37 PM, Andreas Rossberg rossb...@google.comwrote:
On 19 January 2012 07:51, Mark S. Miller erig...@google.com 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
Herby Vojčík mailto:he...@mailbox.sk
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
On Thu, Jan 19, 2012 at 6:11 PM, Mark S. Miller erig...@google.com 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
On Thu, Jan 19, 2012 at 12:44 AM, Andreas Rossberg rossb...@google.comwrote:
On 19 January 2012 07:51, Mark S. Miller erig...@google.com 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
Axel Rauschmayer mailto:a...@rauschma.de
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,
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 rossb...@google.comwrote:
On 19 January 2012 09:00, Andrea Giammarchi
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 restricted
Andreas Rossberg wrote:
On 19 January 2012 18:31, Axel Rauschmayera...@rauschma.de 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
Brendan Eich wrote:
Axel Rauschmayer mailto:a...@rauschma.de
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,
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 either
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 /
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
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
On Thu, Jan 19, 2012 at 1:00 PM, Herby Vojčík he...@mailbox.sk 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
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 mailto:he...@mailbox.sk
January 19, 2012 11:40 AM
François REMY mailto:fremycompany_...@yahoo.fr
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
Mark S. Miller mailto:erig...@google.com
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, just
David Bruant mailto:bruan...@gmail.com
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
David Bruant mailto:bruan...@gmail.com
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 from
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
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
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
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
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
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:
2012/1/19 Kevin Reid kpr...@switchb.org
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;
Axel Rauschmayer mailto:a...@rauschma.de
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
On Thu, Jan 19, 2012 at 8:20 PM, Axel Rauschmayer a...@rauschma.de 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
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 10; i++) {
On Thu, Jan 19, 2012 at 11:02 PM, Brendan Eich bren...@mozilla.org 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
On Fri, Jan 20, 2012 at 2:24 AM, Herby Vojčík he...@mailbox.sk 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
+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 Fri, Jan 20,
38 matches
Mail list logo
