On Sat, Mar 3, 2012 at 11:08 AM, John J Barton
wrote:
> On Sat, Mar 3, 2012 at 6:54 AM, Dean Landolt wrote:
> > One argument for the "wrong direction" being wrong: if A <: B is common
> math
> > syntax for A is a subtype of B, if you turn the arrow around it'd read A
> is
> > a supertype of B, an
> Speaking of compositions though, I can't recall if it was ever discussed
> whether this operator can be chained, and if so, whether it associates. I
> don't see too much value in this since references to any intermediate
> constructions would only be available by walking the proto chain. I can
On Mar 3, 2012, at 8:51 AM, Dean Landolt wrote:
>
> Speaking of compositions though, I can't recall if it was ever discussed
> whether this operator can be chained, and if so, whether it associates. I
> don't see too much value in this since references to any intermediate
> constructions woul
OK, forget that. You could still produce left-hand sides...
On Mar 3, 2012, at 17:57 , Axel Rauschmayer wrote:
>> Speaking of compositions though, I can't recall if it was ever discussed
>> whether this operator can be chained, and if so, whether it associates. I
>> don't see too much value in
One reason that I prefer <| is that I find it easy to think about it as a close
approximation to an atomic symbol such as ◁ (U+35c1). I don't perceive the <
and | as individual elements and hence I don't have any cognitive dissonance
about its meaning. I find this less so wit
On Sat, 03 Mar 2012 01:55:59 +0100, Allen Wirfs-Brock
wrote:
At this stage, choice of a symbol seems to be most about what will cause
the lesser about of opposition based solely upon the symbol choice.
Some people seem top really hate <|. If there a reasonable alternatives
that don't
On Sat, 03 Mar 2012 01:55:59 +0100, Allen Wirfs-Brock
wrote:
At this stage, choice of a symbol seems to be most about what will cause
the lesser about of opposition based solely upon the symbol choice.
Some people seem top really hate <|. If there a reasonable alternatives
that don't
On Sat, 03 Mar 2012 01:55:59 +0100, Allen Wirfs-Brock
wrote:
At this stage, choice of a symbol seems to be most about what will cause
the lesser about of opposition based solely upon the symbol choice.
Some people seem top really hate <|. If there a reasonable alternatives
that don't
On Sat, 03 Mar 2012 19:45:48 +0100, Jonas Höglund
wrote:
[...]
Eek, sorry about the spam. My mail client wasn't properly set up.
Jonas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
#x27;s better to look for more alternatives of
direction-neutral operators instead. Here are some suggestions:
let obj = proto \\ {
prop: "test",
foo: 10
}
let obj = proto #: {
prop: "test",
foo: 10
}
As for the nondirectional ones, does this collide with something?
e
lines `proto is the basis of
object', although the first thing that comes to mind is still `proto
maps to object'.
And yes, this is a nitpick.
On the other hand, there are strong associations of such a symbol with
different semantics
in other languages, property access and functi
e
lines `proto is the basis of
object', although the first thing that comes to mind is still `proto
maps to object'.
And yes, this is a nitpick.
On the other hand, there are strong associations of such a symbol with
different semantics
in other languages, property access and functi
foo: 10
>> }
>> let obj = proto #: {
>> prop: "test",
>> foo: 10
>> }
>
> As for the nondirectional ones, does this collide with something?
>
> let obj = proto ^^ {
>prop: "test",
>foo: 10
> }
This is exceptional
On Mar 3, 2012, at 2:24 AM, Axel Rauschmayer wrote:
> let sub = sup <: {p:1, q:2};
This one has been one my least-objectionable options.
> let sub = sup <~ {p:1, q:2};
Doesn't work; ~ is a unary operator.
> let sub = sup <> {p:1, q:2};
Has a pretty strong "not equal to" connotation.
> let su
On Mar 3, 2012, at 6:54 AM, Dean Landolt wrote:
> I like, though <+ is a little easier on the eyes.
Ambiguous. + is a unary operator.
> One argument for the "wrong direction" being wrong: if A <: B is common math
> syntax for A is a subtype of B, if you turn the arrow around it'd read A is a
>
On Mar 3, 2012, at 1:28 PM, Quildreen Motta wrote:
> <- sounds too much like return (local or not).
And it's ambiguous. - is a unary operator.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mar 2, 2012, at 2:30 PM, Allen Wirfs-Brock wrote:
> What do you think? Do you like -> better than <| ?
I like -> much, *much* better than <|. The latter looks like we ran out of
options but desperately wanted to shoe-horn something into an already heavily
constrained syntax. Which, of course
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
>>> What do you think? Do you like -> better than <| ? Is it ok to not have it
>>> available for some possible future function shorthand?
>
> Both => and -> have strong associations with function shorthands f
quot;test",
>> foo: 10
>> }
>> let obj = proto #: {
>> prop: "test",
>> foo: 10
>> }
>
> As for the nondirectional ones, does this collide with something?
>
> let obj = proto ^^ {
>prop: "test",
>
If we’re taking votes:
-1. I would actively avoid using this in my own ES6 code, because of the
unnecessary confusion it would cause to those coming from CoffeeScript.
From: Carlos Prado García
Sent: Saturday, March 03, 2012 17:58:38
To: es-discuss
Subject: Re: How about replacing <| w
On Sat, Mar 3, 2012 at 5:20 PM, David Herman wrote:
> On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
>
> >>> What do you think? Do you like -> better than <| ? Is it ok to not
> have it available for some possible future function shorthand?
> >
> > Both
On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
> On Sat, Mar 3, 2012 at 5:20 PM, David Herman wrote:
> This argument seems to over-reach. C and C++ use -> for pointer indirection.
> Perl uses -> for method calls.
>
> This is precisely why it can't really be overloaded any further.
It's not "
o
> use => as function shorthand later, due to the syntactic similarity of these
> two operators.
On second thought, that's actually not true. The fact that CoffeeScript uses
both for functions (with different this-binding) behavior is actually not
universally loved; it causes con
e
that actually requires JS itself to exist? I don't think it should matter
either way...
>
> *From:* Carlos Prado García
> *Sent:* Saturday, March 03, 2012 17:58:38
> *To:* es-discuss
> *Subject:* Re: How about replacing <| with ->
>
> +1 for -> syntax.
>
&
On Sat, Mar 3, 2012 at 7:37 PM, David Herman wrote:
> On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
>
> On Sat, Mar 3, 2012 at 5:20 PM, David Herman wrote:
>
>> This argument seems to over-reach. C and C++ use -> for pointer
>> indirection. Perl uses -> for method calls.
>>
>
> This is precise
On Mar 3, 2012, at 5:39 PM, Rick Waldron wrote:
> All I can say is it looks terrible. I don't have any way to quantify that, of
> course.
>
> I will gladly do a survey of the web development community to satisfy any
> requests for qualification.
More information is always welcome. It's always
On Sat, Mar 3, 2012 at 8:52 PM, David Herman wrote:
> On Mar 3, 2012, at 5:39 PM, Rick Waldron wrote:
>
> All I can say is it looks terrible. I don't have any way to quantify that,
>> of course.
>>
>
> I will gladly do a survey of the web development community to satisfy any
> requests for qualif
ng that CoffeeScript should change itself to accommodate
JavaScript, well, maybe Jeremy can comment on how likely that is. Personally I
think es-discuss should be careful not to alienate such a large and growing
fraction of their userbase, especially with comments like the above that see
e ES6 makes it out
> the door.
>
> If you're arguing that CoffeeScript should change itself to accommodate
> JavaScript, well, maybe Jeremy can comment on how likely that is.
> Personally I think es-discuss should be careful not to alienate such a
> large and growing fractio
None of the syntax options presented so far seem to be winning. Would not
specifying the prototype somewhere *inside* of the object literal also be
an option? If so, would anyone like to take a crack at that?
khs
___
es-discuss mailing list
es-discuss@
xplored that path (trace back the history of the object literal
proposals on the wiki). The <| semantics needs to also work with at least
function expressions and array literals.. In the future it probably needs to
be extensible to block lambda. Some thing that is "outside&q
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
a while back, and we discussed alternative contextual keywords. Grawlix
appears to result in (a) strong anti-grawlix reaction from a good part
of the community; (b)
on they imagine it
pointing to, perhaps it's better to look for more alternatives of
direction-neutral operators instead. Here are some suggestions:
let obj = proto \\ {
prop: "test",
foo: 10
}
let obj = proto #: {
prop: "test",
foo: 10
}
As for the nondir
both of these groups seem to think the symbol
>>>> points in the "wrong" direction if it isn't the direction they imagine
>>>> it
>>>> pointing to, perhaps it's better to look for more alternatives of
>>>> direction-neutral
t still feel a
little forced. What is this, the bible?
While we're all throwing our hats in the ring, I will renew my proposal for
extends as a binary prefix operator.
let sub = extends sup {p:1, q:2, r:3};
And I would additionally advocate for a form that combines with declarations
let s
On Sat, Mar 3, 2012 at 11:17 PM, Brendan Eich wrote:
> Dean Landolt wrote:
>>
>> Does it /have/ to be ascii?
>
>
> Does it have to be grawlix? I proposed
>
> let sub = sup beget {p:1, q:2, r:3};
The problem with <| and friends is that the common mental asso
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
> Dean Landolt wrote:
>> Does it /have/ to be ascii?
>
> Does it have to be grawlix? I proposed
>
> let sub = sup beget {p:1, q:2, r:3};
>
> a while back, and we discussed alternative contextual keywords. Grawlix
> appears to result in (a) str
John J Barton wrote:
On Sat, Mar 3, 2012 at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
The problem with<| and friends is that the common mental association
with th
peakers who are trying to learn or use the language. Presumably, that
is (or will be) the majority of ES developers.
Being a native English speaker, I don't have any direct experience with this
(for ES ior other PLs). But we do have non-native speakers on this list and
specific feed back fro
rn about the possible impact of keyword choice on non-native
> English speakers who are trying to learn or use the language. Presumably,
> that is (or will be) the majority of ES developers.
>
> Being a native English speaker, I don't have any direct experience with this
> (
oncern about the possible impact of keyword choice on
> non-native English speakers who are trying to learn or use the language.
> Presumably, that is (or will be) the majority of ES developers.
> >
> > Being a native English speaker, I don't have any direct experience with
Allen Wirfs-Brock wrote:
On Mar 4, 2012, at 9:18 AM, Herby Vojčík wrote:
P.P.S.: I don't know what 'beget' means (I know I can find it,
just to illustrate it's not a commonly known word).
If you don't know the word, is it easier to learn a new symbol (eg
<|) or a new keyword (eg beget)? Lo
't like a lot "->", it can look more friendly at first step, but
can be confusing with other languages's use (makes me think to damn php
stuff)
So I prefer "<|"
Le 03/03/2012 18:35, Allen Wirfs-Brock a écrit :
On Mar 3, 2012, at 8:51 AM, Dean Landolt wrote:
Wh
ommon word, is becoming available, and reads well to me:
let sub = sup with {p:1, q:2, r:3};
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I worry mainly about terminology. Wouldn’t “beget” introduce a new term for
specifying “the prototype of”? Learning a new word in and of itself has never
been a problem for me, especially when it goes along with a new concept.
More possibilities (I know some of these have been suggested before
lla.org
https://mail.mozilla.org/listinfo/es-discuss
My major problem with a spelt out operator is that it gets difficult to
tell it from the surrounding words at a glance. Though it gets a little
better if one has some sort of syntax highlighting support, the symbols
are just easier to spot in the code
prototypical inheritance, as implemented by JavaScript,
has a clear direction, though. It's just a delegation from an object to
a prototype, thus: `super <| (or <:, or <~, or ...) { p: 1, q: 2, r: 3
}' makes sense.
With `super -> { p:1, q: 2, r: 3 }', it could be argued th
possible impact of keyword choice on non-native
> English speakers who are trying to learn or use the language. Presumably,
> that is (or will be) the majority of ES developers.
>
> Being a native English speaker, I don't have any direct experience with this
> (for ES ior other PL
Allen's reach for ◁ is compelling -- is it really so
> bad to just go all in for it?
>
> FWIW I personally think <| is just fine :)
We've never gotten any traction with adopting non-ascii syntactic characters
and for good reasons.
However, we generally have looked at th
On Sun, 04 Mar 2012 20:36:31 +0100, Axel Rauschmayer
wrote:
Experiment: I’ve written down the proposals that have been made so far,
to reduce the circles we are going in. Let me know of any corrections or
additions I should make.
https://docs.google.com/spreadsheet/ccc?key=0Apu8J_NsHwGGd
or use the language.
> Presumably, that is (or will be) the majority of ES developers.
> >
> > Being a native English speaker, I don't have any direct experience with
> this (for ES ior other PLs). But we do have non-native speakers on this
> list and specific feed back f
gt;
These are extremely helpful - thank you for sharing. It's very clear to me
that a symbol/operator is the obvious choice when faced with a large code
example - "beget" just gets lost, where <| is very noticeable and very
obvious (and even helped me to better understand the outcom
samples that differ only in the use of
>> "beget" in place of <|
>>
>> Compare:
>>
>>
>> https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
>>
>>
>> and
>>
>>
>> https://github.com/al
Hello,
I feel uneasy about this in <| proposal:
If the LHS operand has a property named prototype and the RHS
operand is a function expression then the [[Prototype]] of the
function object is set to the LHS object and the prototype property
of the new function is set to a new object whose [[Pro
t sized code samples that differ only in the use of
>>> "beget" in place of <|
>>>
>>> Compare:
>>>
>>>
>>> https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
>>>
>>>
>>> and
>>
s that differ only in the use
>>>> of "beget" in place of <|
>>>>
>>>> Compare:
>>>>
>>>>
>>>> https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js
>>>>
>>>>
;>>> I have two significant sized code samples that differ only in the use
>>>>> of "beget" in place of <|
>>>>>
>>>>> Compare:
>>>>>
>>>>>
>>>>> https://github.com/allenwb/ESnext-experiments/
On 3 March 2012 02:06, Luke Hoban wrote:
>>>>>> What do you think? Do you like -> better than <| ? Is it ok to not have
>>>>>> it available for some possible future function shorthand?
>>>
>>> Both => and -> have strong assoc
On 3 March 2012 23:20, David Herman wrote:
> On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
>
>>>> What do you think? Do you like -> better than <| ? Is it ok to not have
>>>> it available for some possible future function shorthand?
>>
>> Both
On 1 March 2012 19:34, Allen Wirfs-Brock wrote:
> What do you think? Do you like -> better than <| ? Is it ok to not have
> it available for functions?
>
I am always reticent to re-use lexical features of one language when
implementing in another with wildly different semanti
(wow I don't know where these stale message came fromplease ignore)
On Mar 1, 2012, at 4:21 PM, Allen Wirfs-Brock wrote:
> It was recently suggest to me that it is unlikely that we will ever adopt ->
> as as function expression shorthand symbol and that this means we could
> consider using
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
Only a couple of TODOs:
11.1.7.1 [[Call]]
When the [[Call]] internal method for a block-lambda object B is called with a
list of arguments, the following steps are taken:
Let funcCtx be the result of establishing a new
Le 18/12/2011 14:43, Herby Vojčík a écrit :
> Hello,
>
> I've come with the idea how to let proxies forward private names
> without compromising the private name and the value stored under it,
> as well.
It is an interesting idea, but is there a use case associated with this
David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>> Mark S. Miller wrote:
>>> [...] I recommend the per-iteration view. If we can
>>> agree quickly on per-iteration, then
>>>
>>> for (const x = ...) {...x...}
>>>
>>> should be allowed in ES3.1 (whether or not const hoists to block
>>> st
- good for it).
This is an error according to ES1-3 because x++ is a postfixExpression
derived from
PostfixExpression :
LeftHandSideExpression
LeftHandSideExpression [no LineTerminator here] ++
LeftHandSideExpression [no LineTerminator here] --
while expr()
On Oct 17, 2008, at 3:39 PM, Brendan Eich wrote:
> On Oct 17, 2008, at 12:25 PM, Waldemar Horwat wrote:
>
>> Here's a clearer case that Firefox gets wrong (or your grammar gets
>> wrong, depending on your point of view):
>>
>> function f() {return "f"}
>> var x = 3;
>> let (a = 1) a ? f : x++();
>
this point. The rest of
> my post is about x++() not being a valid sentence, which supports your
> argument.
>
> While we don't have any usability problems, and torturous statements
> such as
>
> let (a = 1) a ? f : x++();
>
> are not written by real users (they&#
hich supports your
>> argument.
>>
>> While we don't have any usability problems, and torturous statements
>> such as
>>
>> let (a = 1) a ? f : x++();
>>
>> are not written by real users (they'd parenthesize to clear up
>> things), I agree
On Oct 17, 2008, at 4:16 PM, Waldemar Horwat wrote:
> The old ES4 grammar is machine-verified LR(1). It's on:
>
> http://www.mozilla.org/js/language/old-es4/
One based on ES3 would be helpful for ES3.1 and Harmony. Someone needs
to invest effort here. If not you, who? This is as good a time as
Brendan Eich wrote:
> On Oct 17, 2008, at 4:16 PM, Waldemar Horwat wrote:
>
>> The old ES4 grammar is machine-verified LR(1). It's on:
>>
>> http://www.mozilla.org/js/language/old-es4/
>
> One based on ES3 would be helpful for ES3.1 and Harmony. Someone needs
> to invest effort here. If not you
On Oct 20, 2008, at 11:35 AM, Waldemar Horwat wrote:
> Brendan Eich wrote:
>> On Oct 17, 2008, at 4:16 PM, Waldemar Horwat wrote:
>>> The old ES4 grammar is machine-verified LR(1). It's on:
>>>
>>> http://www.mozilla.org/js/language/old-es4/
>> One based on ES3 would be helpful for ES3.1 and Harm
ascript.org/doku.php?id=strawman:strawman
> pages and (other than let expressions,
Or (in the case of http://wiki.ecmascript.org/doku.php?id=strawman:lambdas)
lambda with expression body syntax, as opposed to block body syntax.
/be
> which are already found
> wanting) validating or invalidati
On Mon, Jun 22, 2009 at 2:43 PM, Mike Wilson wrote:
> I sympathize with the slide "Problem: Can't emulate
> platform objects" (which is addressed by e g getter/setter
> properties), but the removal of with(){} in ES5 strict mode
> would mean it gets harder to emulate the
On Jun 23, 2009, at 5:18 PM, Jason Orendorff wrote:
On Mon, Jun 22, 2009 at 2:43 PM, Mike Wilson
wrote:
I sympathize with the slide "Problem: Can't emulate
platform objects" (which is addressed by e g getter/setter
properties), but the removal of with(){} in ES5 strict mod
On Tue, Jun 23, 2009 at 5:13 PM, Juriy Zaytsev wrote:
> Last time I checked, most of the browsers actually *still were augmenting
> scope* of event handlers as if by using "with". There's been some research
> on this subject first by Cornford, then by Garrett Smith. Most
Jason Orendorff wrote:
> Eeuuurgh. In that case, what David-Sarah said.
What did he say?
Best regards
Mike
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Jun 24, 2009, at 11:38 AM, Mike Wilson wrote:
Jason Orendorff wrote:
Eeuuurgh. In that case, what David-Sarah said.
What did he say?
He said "don't do that", to paraphrase. Full quote:
"The 'with' can be in non-strict code, which is perfectly
adequa
Brendan Eich wrote:
> On Jun 24, 2009, at 11:38 AM, Mike Wilson wrote:
>
> > Jason Orendorff wrote:
> >> Eeuuurgh. In that case, what David-Sarah said.
> >
> > What did he say?
>
> He said "don't do that", to paraphrase. Full quote:
>
&g
On Wed, Jun 24, 2009 at 12:02 PM, Brendan Eich wrote:
> On Jun 24, 2009, at 11:38 AM, Mike Wilson wrote:
>
>> Jason Orendorff wrote:
>>>
>>> Eeuuurgh. In that case, what David-Sarah said.
>>
>> What did he say?
>
> He said "don't do that&
>>>
>>> What did he say?
>>
>> He said "don't do that", to paraphrase. Full quote:
>>
>> "The 'with' can be in non-strict code, which is perfectly
>> adequate for implementing a backward-compatible misfeature
>> (the
ng, I mean) level.
If HTML 5 author(s) only had the hindsight to see the problems with
their inventions. I don't expect much at this point.
Careful with pronouns -- HTML 5 spec writers did not create nested
scopes for event handlers, I did. They are just paving this particular
cowpath
; It seems a bit like the callable collections that MSIE started.
>
> Agreed, at a gut-feel (churning, I mean) level.
>
>
>> If HTML 5 author(s) only had the hindsight to see the problems with
>> their inventions. I don't expect much at this point.
>
> Careful with pro
ue){
> return function(e){
> with(document){
> with(element){
> var fn = eval('(function(event){' + attrValue + '})');
This is eval'ing in the current lexical context. You want a global eval.
In ES5:
var evil = eval;
onent in these expressions."
this is then followed by:
"NOTE By mutual agreement of the partners in information interchange,
the character [T] may be omitted in
applications where there is no risk of confusing a date and time of
day representation with others defined in this
Inter
timestamp it is easy enough for them to
replace the "T" with a blank.
Allen
>-Original Message-
>From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
>boun...@mozilla.org] On Behalf Of William Edney
>Sent: Friday, July 17, 2009 2:21 PM
>To: David-Sarah Hop
ted .toISOTimeString,
.toISODateString and a .toISOString which was based on it.
When I came up with prototypes to add for MonkeyScript (still just
drafting) I followed that same idea:
http://draft.monkeyscript.org/api/_std/Date.html
((Of course, I'll modify the MonkeyScript drafts to comply w
Consider:
Object.defineProperty(obj, propname, { get: undefined, set: undefined });
Assuming obj has no property named by propname (whether it does or not is
basically irrelevant to this question), the given expression apparently defines
a property with this property descriptor
That's more compact, but is it worth adding keywords (where) and
complexity when you can easily write:
for each (book in books)
{
if (100>book.pages)
continue;
do();
}
On 10 Oct, 2009, at 9:41 AM, memo...@googlemail.com wrote:
Compare:
for each(book in books where book.page
A bit off topic:
FF had a second argument to eval which enabled a form of sandboxing
but was removed due to security issues - peeking into closures:
https://bugzilla.mozilla.org/show_bug.cgi?id=442333
With ES5 strict mode and the ability to freeze objects could this eval
be 'resurrected&#
Any thoughts on whether (eval(a, b)) should be an invocation of the
eval operator?
2010/1/8 Mike Samuel :
> Should it be the case that invoking unoverridden eval with 0 or 2 or
> more arguments is an EvalError, regardless of whether the call is
> direct or not?
>
> What is the beha
On Jan 14, 2010, at 6:27 PM, Mike Samuel wrote:
Any thoughts on whether (eval(a, b)) should be an invocation of the
eval operator?
What do current browsers do? It's an eval operator in Mozilla-based
browsers. Seems to be eval (dynamic scope, not global scope) in Safari
too.
What would be
eval (dynamic scope, not global scope) in Safari too.
>
> What would be the benefit of changing a future edition to make such an eval
> "indirect"?
I am not advocating changing eval in a future edition.
What I found confusing was that the previous section started with
"W
ms to be eval (dynamic scope, not global scope) in
Safari too.
What would be the benefit of changing a future edition to make such
an eval
"indirect"?
I am not advocating changing eval in a future edition.
What I found confusing was that the previous section started with
benefit of changing a future edition to make such an
>>> eval
>>> "indirect"?
>>
>> I am not advocating changing eval in a future edition.
>>
>> What I found confusing was that the previous section started with
>> "When the eval function
On Mar 4, 2012, at 1:59 PM, Herby Vojčík wrote:
> Hello,
>
> I feel uneasy about this in <| proposal:
>
>> If the LHS operand has a property named prototype and the RHS
>> operand is a function expression then the [[Prototype]] of the
>> function object is set to the LHS object and the prototyp
is ok.
I was in the impression, that the behaviour differs in principle, and
that different object are put in RHS.[[Prototype]]. I don't know why I
thought that.
Maybe to clear that confusion, should it happen with others, it should
be formulated in some way that dispels it.
Sorry for
Herby Vojčík wrote:
the same: it is set as a {[Prototype]] of the RHS. Putting LHS.prototype
into RHS.prototype is pure "addon". Seeing it this way, it is ok.
LHS and RHS should be switched in the sentence.
I was in the impression, that the behaviour differs in principle, and
that different
I was in the impression, that the behaviour differs in principle, and
that different object are put in RHS.[[Prototype]]. I don't know why I
RHS should be here.
LHS. These abbreviations are probably cursed in my case.
___
es-discuss mailing list
es-dis
On Mar 5, 2012, at 2:45 AM, Herby Vojčík wrote:
>>> I was in the impression, that the behaviour differs in principle, and
>>> that different object are put in RHS.[[Prototype]]. I don't know why I
>> RHS should be here.
> LHS. These abbreviations are probably cursed in my case.
>
Welcome to the
Perhaps this will help conceptually:
All objects are created with a [[Prototype]] value. Each kind of literal has a
default value that is used set the [[Prototype]] value. All <| does is allow
an alternative value to be used to set [[Prototype]]. Function expression
"literals"
101 - 200 of 601 matches
Mail list logo
