Re: Putting `global` reference in specs
At some point in the past, I proposed that we introduce syntax for that. In my
proposal, prefixing an identifier with a . would create an unambiguous
reference to the global version of that variable.
For example:
```js
var x;
function f(x) {
x; // local
.x; // global
}
```
This is an idea I borrowed from C++'s :: operator.
From: Mark Miller erig...@gmail.commailto:erig...@gmail.com
Date: Friday, April 17, 2015 at 8:53 AM
To: Glen Huang curvedm...@gmail.commailto:curvedm...@gmail.com
Cc: Mark S. Miller erig...@google.commailto:erig...@google.com,
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: Putting `global` reference in specs
This is one of several cases where, post ES6, we can provide a std module
import that provides a built-in that carries authority. Another example is the
constructor for making weak references, which necessarily provide the ability
to read a covert channel. As with shadowable globals, this module import must
be easy to virtualize. We purposely postponed this along with the Loader and
Realm API as it is security sensitive and we don't yet have enough usage
experience with modules to know how to design this separation well.
In particular, we rejected the obvious Reflect.global as it bundles the global
together with authority-free safe things, which makes virtualization of the
global alone needlessly unpleasant.
On Fri, Apr 17, 2015 at 8:45 AM, Glen Huang
curvedm...@gmail.commailto:curvedm...@gmail.com wrote:
You guys are talking about referencing the global object in modules right?
Since in scripts you can reliably get hold of the global object by using this
in the root scope.
And es 2015 made an explicit choice to clobber this in the root scope of a
module, I guess that means module code really isn't supposed to get hold of the
global object?
On Apr 17, 2015, at 11:34 PM, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
I almost omitted it, but one should never need to encounter or think about
sloppy code unless absolutely necessary. For my brain, adding the use strict;
makes this snippet of code much simpler.
On Fri, Apr 17, 2015 at 8:30 AM, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 17 April 2015 at 17:27, Mark S. Miller
erig...@google.commailto:erig...@google.com wrote:
(1,eval)('use strict; this')
Is the 'use strict' relevant here? Seems overkill.
/Andreas
On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
there's actually no way, officially, to reference what ES2015 call *the global
object*, just pointless fragmentation between engines.
On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren
ann...@annevk.nlmailto:ann...@annevk.nl wrote:
On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
So I'd say we should not have `self` (if stays on global and Worker I don't
actually care) and add a `global` that nobody needs explanation to
understand what it is in JavaScript
Indeed, three ways to reference the global object is not nearly enough.
--
https://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail (including
the original message in your reply) and then delete and discard all copies of
the e-mail.
Thank you.
-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Date.prototype.toISOString and fractional parts
According to the spec, the toISOString is currently defined to return a string in the format -MM-DDTHH:mm:ss.sssZ. Specifically, there's a 3-digit fractional part introduced by a . (that's the .sss above) appended to the seconds. It is my understanding of the ISO8601 spec that fractional parts can start with either a dot or a comma, and that the number of digits in the fractional part needs to be agreed upon by both parties using that format. If my interpretation is correct, the current behavior seems to be problematic, in that if an API accepts more (or fewer) than 3 fractional digits, the result of this function needs to be further modified before they can be used against said API. Same goes for dot vs. comma. Would it make sense then to augment the spec to have toISOString take optional parameters Date.prototype.toISOString([precision[, separator]])? Thanks - This e-mail is intended only for the use of the addressees. Any copying, forwarding, printing or other use of this e-mail by persons other than the addressees is not authorized. This e-mail may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient, please notify us immediately by return e-mail (including the original message in your reply) and then delete and discard all copies of the e-mail. Thank you. - ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object copy
And maybe there should be a Object.move for value types...
From: Frankie Bagnardi f.bagna...@gmail.commailto:f.bagna...@gmail.com
Date: Tuesday, June 10, 2014 at 2:47 PM
To: Alex Kocharin a...@kocharin.rumailto:a...@kocharin.ru
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: Object copy
I'd like Object.merge(source, dest), and Object.clone(source).
Object.clone would be best if it cloned almost any object, like more advanced
clone functions. This includes plain objects, arrays, instances of classes
(preserving base class, etc.), regExp, promise, and ideally DOM nodes in
browsers (along with anything else that can be cloned). If something can't be
cloned, including primitives and functions, it should throw an error.
Object.merge would be a much simpler copy enumerable own properties function.
Object.merge({a: 1}, {}); and Object.clone({a: 1}); would be equivalent, but
they differ in most other cases.
On Tue, Jun 10, 2014 at 10:38 AM, Alex Kocharin
a...@kocharin.rumailto:a...@kocharin.ru wrote:
Object.create() ?
It's not exactly cloning, but it'll probably work better than cloning in most
cases.
10.06.2014, 20:33, Maxime Warnier mar...@gmail.commailto:mar...@gmail.com:
Hi All
Do you know if it is planned or maybe in discussion for ES7 to have a simple
clone system on objects ?
There are different notations, from :
- jquery
Object.clone( [withDataAndEvents ] [, deepWithDataAndEvents ] )
( but only for DOM element )
- underscore
_.clone(object)
( return the cloned object )
- angular
angular.copy(source, [destination]);
(return the object, same as underscore, or copy into an optional destination )
Maybe an Object.copy([options?]) would be interesting ?
Maxime
Maxime Warnier
@maxdow
,
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail (including
the original message in your reply) and then delete and discard all copies of
the e-mail.
Thank you.
-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level Function Declarations
We don't need an identifier for global. Much like with the :: operator in C++,
a member expression starting with a . would always refer to the global object.
So if you want to refer to member foo in the global object, .foo would be
unambiguous.
I feel like it's a simple, yet elegant solution.
--F
From: John Barton johnjbar...@google.commailto:johnjbar...@google.com
Date: Thursday, June 5, 2014 at 10:55 AM
To: Andreas Rossberg rossb...@google.commailto:rossb...@google.com
Cc: es-discuss es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Re: A bit confused by B.3.2 - Web Legacy Compatibility for Block-Level
Function Declarations
Assigning to 'this' because it happens that 'this' is global is no better and
perhaps worse than using undeclared variables for globals. Assignments to
global have, well, non-local consequences: they should be explicit not context
dependent.
Even if you don't agree, node has made global the de facto standard; lots of
code is now written with the (function(global) {...}(typeof global !==
'undefined' ? global : this)); goop. Modules avoid the smaller part of that
boilerplate but we still don't solve it all without a way to say global.
On Thu, Jun 5, 2014 at 7:34 AM, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 5 June 2014 16:08, John Barton
johnjbar...@google.commailto:johnjbar...@google.com wrote:
On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com
wrote:
On 4 June 2014 23:46, John Lenz
concavel...@gmail.commailto:concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code, but there are places
you
need it (using eval to introduce new symbols into global scope).
You don't necessarily need sloppy mode for that. In strict mode, you
can still express it as assignment to the global object.
This excellent solution would be much more widely adopted if the global
object had a standard identifier, like say global.
Hm, I'm not sure why that would be a problem. What's wrong with using
'this' inside those evals?
/Andreas
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail (including
the original message in your reply) and then delete and discard all copies of
the e-mail.
Thank you.
-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Bytecode
I kind of feel that even if such a bytecode existed, it should be immaterial to the design of ES. What I'm trying to say is that probably a better place for this discussion is at the web standards level. This decision can be completely outside of the design of any individual language, provided a generic enough bytecode. Now obviously being able to have web apps written in different languages while maintaining performance and debuggability would be nice. But for me, the main benefit of the bytecode is having my engineering team be able to adopt newer versions of the language at our convenience (instead of waiting 10 years until some ancient client updates their script engine)... From: Andrea Giammarchi andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com Date: Friday, May 16, 2014 at 3:25 PM To: Oliver Hunt oli...@apple.commailto:oli...@apple.com Cc: es-discuss list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org Subject: Re: Bytecode Sure Oliver, it's just funny to read very old unmaintained libraries as the base code to test LLVM IR on top ... what you say makes sense but then I'd expect some new library maybe based on some new ES5 feature too, that's all I was trying to say and there was nothing about criticizing the awesome job WebKit did there. Take Care On Fri, May 16, 2014 at 9:43 AM, Oliver Hunt oli...@apple.commailto:oli...@apple.com wrote: On May 15, 2014, at 10:24 PM, Andrea Giammarchi andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote: but you mentioned very old one I think nobody cares much anymore ;-) People may not care about them today, but that doesn't mean that no one uses them - there are many millions of webpages that use these libraries still, and that means performance of those libraries is extremely important to end _users_. Regarding the original topic of this thread: I think there have been many many prior discussions of a standardised bytecode on es-discuss, and people should really be reading those before bringing this up again. It's not going to happen as no one has ever demonstrated an actual benefit over simply using JS. -Oliver - This e-mail is intended only for the use of the addressees. Any copying, forwarding, printing or other use of this e-mail by persons other than the addressees is not authorized. This e-mail may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient, please notify us immediately by return e-mail (including the original message in your reply) and then delete and discard all copies of the e-mail. Thank you. - ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
I agree with you that this would be a much better design, but it would break
backwards compatibility with ES5, no?
Minor nitpick: I guess you mean to say that ToPropertyDescriptor should use the
abstract operation HasOwnProperty, not [[HasOwnProperty]]...
Fred
From: John-David Dalton
john.david.dal...@gmail.commailto:john.david.dal...@gmail.com
Date: Thursday, May 8, 2014 at 1:25 PM
To: es-discuss Steen es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: ToPropertyDescriptor, [[HasProperty]], [[HasOwnProperty]]
ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the keys
of `source` objects. This helps avoid the method gotchas faced by developers
previously with things like `Object.prototype.writable = true` and
`Object.defineProperty(o, 'foo', { value: 'bar' })`.
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty#Description
(bottom of section)
Bear in mind that these options are not necessarily own properties so, if
inherited, will be considered too. In order to ensure these defaults are
preserved you might freeze the Object.prototype upfront, specify all options
explicitly, or point to null as __proto__ property.
It's the reason I pre-populate my descriptor attributes with false even though
false is the default. See
https://github.com/lodash/lodash/blob/2.4.1/dist/lodash.js#L112-L117
With methods like Object.assign using [[OwnPropertyKeys]] does it make sense to
make things like ToPropertyDescriptor use [[HasOwnProperty]] too. I think it
would be a win for consistency and dev use.
Thoughts?
- JDD
-
This e-mail is intended only for the use of the addressees. Any copying,
forwarding, printing or other use of this e-mail by persons other than the
addressees is not authorized. This e-mail may contain information that is
privileged, confidential and exempt from disclosure. If you are not the
intended recipient, please notify us immediately by return e-mail (including
the original message in your reply) and then delete and discard all copies of
the e-mail.
Thank you.
-
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
