On Mon, Jun 30, 2014 at 10:18 AM, raul mihaila raul.miha...@gmail.com
wrote:
While reading the SetPrototypeOf algorithm I noticed that some steps are
repeated. At step 5, if O.[[Extensible]] is false, the method returns
false. But at step 8, the same condition is checked again. It seems to me
This is probably an absurd idea and I have no idea if it can be actually
made to work for host objects, but wanted to throw it in the air to see if
it has any viability and could be polished.
As we all know, mixins are a strongly ingrained pattern in JS out in the
wild. One notable example is the
On 28 June 2014 20:23, Rick Waldron waldron.r...@gmail.com wrote:
On Saturday, June 28, 2014, Brendan Eich bren...@mozilla.org wrote:
Ok, nerdbait -- but I'll take it and champion it at the next TC39 meeting.
Thanks,
Yes, if you hadn't I would've :)
I doubt there will be an opposition, but
Although I'm a mathematician, I don't want to argue from a mathematical point
of view against the inclusion of Math.TAU
(For this please read the http://www.thepimanifesto.com/ which was already
posted above by Michael).
But instead from a JavaScript point of view:
The only arguments in favor
On 27 June 2014 21:45, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg rossb...@google.com
wrote:
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
is a
It's pretty useless to have. If you need the TAO constant often, rather
than setting it on Math you'd be better off having local variables. This
is both for conciseness and minification (minified Math.TAO is Math.TAO,
minified TAO is a single character).
```javascript
var PI = Math.PI, TAO = PI
I'd just like to add that joke requests like Math.TAU that have no place
in the language specification itself generate a considerable amount of
overhead for those of us who keep up with the mailing list.
Especially since the other topics discussed are interesting (e.g.
ModuleImport ). I think it
On 6/30/14, 5:37 AM, Jussi Kalliokoski wrote:
However, the key thing is that it could be applied to any given object, not just
instances of the host object.
The problem with this is that it requires either allocating the hidden
state outside the object itself somewhere or requiring all
I'd just like to add that joke requests like Math.TAU that have no
place in the language specification itself generate a considerable
amount of overhead for those of us who keep up with the mailing list.
I don't think asking for Math.TAU was a joke request. It's rather a
request for a
Let me try to restate my request for clear information on the advantages of
module bindings vs module object architectures.
The import syntax already allows pre-execution tools to collect every
module that will be accessed by a root dependent module (including some
that may not be used). This
On Sun, Jun 29, 2014 at 1:00 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
On Jun 29, 2014, at 12:50, Rick Waldron waldron.r...@gmail.com wrote:
Static analysis would be necessary if JavaScript ever wanted to make
macros possible in modules. I don't have exact numbers nor have I
Le 29 juin 2014 à 00:36, Domenic Denicola dome...@domenicdenicola.com a écrit
:
This looks nice to me as well. But given the length I had trouble
internalizing in what externally-visible ways it would change the status quo,
especially with the optional @@create addition. The writeup as-is
Le 29 juin 2014 à 04:46, Kevin Smith zenpars...@gmail.com a écrit :
Thanks Claude for working this up.
InitializeThisBindings(nonconstructedObj, obj) abstract operation
--
This operation performs the actual
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg rossb...@google.com
wrote:
...this is why I've been arguing strongly for consistent syntax
regardless.
Static checking and lazy binding should be value added features, not
something I have to think about every time I import a module.
On Mon, Jun 30, 2014 at 10:27 AM, Jan Keromnes j...@mozilla.com wrote:
I'd just like to add that joke requests like Math.TAU that have no
place in the language specification itself generate a considerable
amount of overhead for those of us who keep up with the mailing list.
I don't think
On Mon, Jun 30, 2014 at 1:01 PM, Rick Waldron waldron.r...@gmail.com
wrote:
Just because other languages don't include a TAU constant doesn't mean
ECMAScript cannot.
Just because serious mathematicians think this is crackpot territory,
doesn't mean it's not useful (the condescension of that
On 30 June 2014 19:01, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Jun 30, 2014 at 10:27 AM, Jan Keromnes j...@mozilla.com wrote:
I'd just like to add that joke requests like Math.TAU that have no
place in the language specification itself generate a considerable
amount of overhead for
On 30 June 2014 19:01, C. Scott Ananian ecmascr...@cscott.net wrote:
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg rossb...@google.com
wrote:
...this is why I've been arguing strongly for consistent syntax
regardless.
Static checking and lazy binding should be value added features,
On Mon, Jun 30, 2014 at 1:26 PM, Andreas Rossberg rossb...@google.com
wrote:
On 30 June 2014 19:01, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Jun 30, 2014 at 10:27 AM, Jan Keromnes j...@mozilla.com wrote:
I'd just like to add that joke requests like Math.TAU that have no
place
As specified in the latest draft:
1. JSON.stringify(symbol) returns undefined.
2. JSON.stringify([symbol]) returns [null].
3. JSON.stringify(object) skips any symbol-keyed properties on the object.
So far, so good, I guess. A little wonky maybe, but JSON doesn't have
symbols, so sure.
This
On Mon, Jun 30, 2014 at 4:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/14, 5:37 AM, Jussi Kalliokoski wrote:
However, the key thing is that it could be applied to any given object,
not just
instances of the host object.
The problem with this is that it requires either allocating
On 6/30/14, 3:00 PM, Jussi Kalliokoski wrote:
There are various approaches to that, all cost something, but the
current approach is not free either.
Sure.
One heavy-handed optimization for
the poor performance common case is to have Object's struct contain a
pointer to a Node's host object
JSON.stringify also skips function-valued properties, which seems even more
weird. I think this is fine as long as it can be overridden by replacers
and resolvers.
On Mon, Jun 30, 2014 at 11:37 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
As specified in the latest draft:
1.
It's not just about interoperability. It's also about enabling the pattern
that proved itself to work quite well - module as a function, module as a
class, module as a function with named exports attached in one namespace.
I suppose if that pattern is not explicitly supported it might be just
On Jun 30, 2014 3:59 PM, Karolis Narkevičius karoli...@gmail.com wrote:
In fact, doesn't being able to import things like above make es6 modules
already interoperable with CJS?
Almost, but not quite, since the name of the module itself ($, fs, etc) is
not included in a typical commonjs module.
It's not just about interoperability. It's also about enabling the pattern
that proved itself to work quite well - module as a function, module as a
class, module as a function with named exports attached in one namespace.
But we have to ask why that pattern worked out, and my take is that
Another interoperability issue is circular dependencies, es6 modules have
support for certain kinds that cjs doesn't (like function declarations)
and cjs has support for 2 modules using each others exports (as long as
they arn't single exports).
If it wasn't for this you could load cjs modules
On Mon, Jun 30, 2014 at 12:00 PM, Kevin Smith zenpars...@gmail.com wrote:
What's not clear is the advantage of module bindings form for modules.
When the world of possibilities opens up, what specific things will I see
there?
I think I'm following you now. So let's pose the question like
On Mon, Jun 30, 2014 at 6:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/30/14, 4:40 AM, Anne van Kesteren wrote:
Are stack overflow exceptions even a thing per standards?
No.
However, they come up pretty regularly in practice. In fact, some sites
depend on them for proper functioning.
alawatthe wrote:
Brendan you said once that Math is becoming a dumping ground see
here
https://mail.mozilla.org/pipermail/es-discuss/2013-November/034610.html
(So it surprised me much, that you want to champion Math.TAU at the
next TC39 meeting.)
Champion is TC39 code-word for advocate, but
On Mon, Jun 30, 2014 at 4:32 PM, John Barton johnjbar...@google.com wrote:
Based on other discussion on this point, it seems like
module-as-named-bindings can interoperate with CJS and AMD except perhaps
in some unusual cases. Clarifying these cases would help.
To me, these two lists are
- Mutable bindings
As far as I know, this is not something JS developers understand. What is
it and what makes it an advantage?
Since imported bindings are just aliases for variables over in the
originating module, changing the value of that variable in the exporting
module will change
30.06.2014, 21:09, "C. Scott Ananian" ecmascr...@cscott.net:On Mon, Jun 30, 2014 at 1:01 PM, Rick Waldron waldron.r...@gmail.com wrote:Just because other languages don't include a TAU constant doesn't mean ECMAScript cannot. Just because "serious mathematicians" think this is "crackpot
It also skips explicit undefined values. Basically, if there's no good
JSON representation of something, it pretends it doesn't exist.
You can also get this behavior by doing `obj.toJSON = () = undefined`
[example fiddle][1]
In all of those cases symbols behave as if they were the value
If there is no module object overwriting, then I suppose it could be
inlined. If you allow overwriting, then you would need the further
restriction that you cannot import from overridden module objects.
Sorry, strike the second sentence. (Trying to do too many things at once!)
String.prototype.endsWith and Object.is are functions, and their JS
implementations are nontrivial to memorize and type (although not the worst
examples). Memorizing PI to more than a few digits is nontrivial. Same
with Math.E, or Math.atan2, or most of the other Math functions and
properties.
On 6/30/14, 3:38 PM, Jussi Kalliokoski wrote:
On Mon, Jun 30, 2014 at 10:16 PM, Boris Zbarsky bzbar...@mit.edu
Would it help the discussion if UA implementors described how they
solve these problems now?
Yess, please! +
On Monday, June 30, 2014, Frankie Bagnardi f.bagna...@gmail.com wrote:
String.prototype.endsWith and Object.is are functions, and their JS
implementations are nontrivial to memorize and type (although not the worst
examples). Memorizing PI to more than a few digits is nontrivial. Same
with
If we're going to have convenience multiples of PI, they should be a)
non-ideological, and b) include more than one (PI/2 comes up a lot in
vector math, for example).
Why not have:
Math.PI
Math.DPI //double pi
Math.HPI //half pi
Or perhaps we should just let people define their own constants.
39 matches
Mail list logo
