Clear rules would also help in discussions like this one:
https://code.google.com/p/v8/issues/detail?id=3006
Background:
V8 implemented a new version of sin and cos, which is faster, but does not have
the precision many user want.
One of the comments (#8) said about precision:
- The ECMA script
Hi Calvin,
On 21 juil. 2014, at 17:16, Calvin Metcalf
calvin.metc...@gmail.commailto:calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
Just to be exact this wouldn't be exactly a CommonJS module
'0101'.replace('0', function(){return 1}) == '1101'
so your last two are the same:
replace(string, callback) - called one time, using the first indexOf and
replacing it invoking the callback
replace(string, string) - called one time, using the first indexOf and
replacing it via provided string
You can also do a split-join to get a literal replace.
I'll sell this for {cost}..split({cost}).join($5.00);
I'll sell this for $5.00.
On Tue, Jul 29, 2014 at 9:36 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
'0101'.replace('0', function(){return 1}) == '1101'
so your last
Hey all,
I just read a bit about the ParallelJS project, Typed Objects
(StructType) and was curious if I could implement bindings for v8 today.
Link to wiki document:
http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects
I realized that I don't know what to do if someone has code
On Jul 29, 2014, at 12:02 PM, Christoph Martens cmarten...@gmail.com wrote:
Hey all,
I just read a bit about the ParallelJS project, Typed Objects (StructType)
and was curious if I could implement bindings for v8 today.
Link to wiki document:
Christoph Martens wrote:
Also, you could solve the typeof null; problem with such a thing
without invalidating legacy code.
You missed the whole previous lifetime many of us lived :-P.
http://esdiscuss.org/topic/es6-doesn-t-need-opt-in (1JS o.p. -- note
that some aspects are out of date)
On 29.07.2014 21:20, Brendan Eich wrote:
Christoph Martens wrote:
Also, you could solve the typeof null; problem with such a thing
without invalidating legacy code.
You missed the whole previous lifetime many of us lived :-P.
http://esdiscuss.org/topic/es6-doesn-t-need-opt-in (1JS o.p. --
split-join to get a literal replace
You really think this is a good design, when for simple string-replace one
should use string-split to create an array, and afterwards join it? This is a
hacky workaround.
better familiarity with the existing capabilities
Rick has pointed for a function
On Mon, Jul 28, 2014 at 10:29 PM, Christoph Martens cmarten...@gmail.com
wrote:
On 28.07.2014 17:24, Rick Waldron wrote:
On Mon, Jul 28, 2014 at 11:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/28/14, 11:09 AM, Rick Waldron wrote:
var y = x.replace('{{blob}}', function() {
The exp function in V8 has a similar issue
https://code.google.com/p/v8/issues/detail?id=3468
as do the recently added hyperbolics
https://code.google.com/p/v8/issues/detail?id=3266
These issues are not limited to the V8 environment. As noted in the
spreadsheet, other browsers exhibit similar
Of course it's a hack :-)
So, moving forward, it'd have to be an extra method on strings, that only
provides a small change in behavior. It's probably not going to happen
because it's such a small change.
Potentially a S.p.replaceAll which has the same behavior as split-join in
that: a b a c a
Would be nice to use something similar that mozilla now does: replace(string,
mix, ?flags), but so that flags are also applied for strings. It wont break
nothing as when (string, string) is used, then usual behaviour is applied, but
with flags the behaviour is extendible, it would be possible
Allen Wirfs-Brock wrote:
Maybe that made sense in the absence of return() but now that we have return
(). yield* is really just a loop that the throw() is terminating early. From
that perspective it seens we should invoke return() and not throw on the inner
iterator.
Good point, sorry I
Allen Wirfs-Brock wrote:
Now that we have return() it isn't clear to me that we actually need
throw() or whether for-of/yield* should call throw() like they
currently do.
Wait, throw is useful anyway, for exception-throwing apart from
returning. Right?
Also I do not know what you mean by
Andy Wingo wrote:
As a matter of design policy we rarely, if ever, just drop exceptions.
I probably didn't explain myself completely; apologies. I meant that
the mechanism of iter.return() should be implemented by throwing an
exception (i.e., as if by iter.throw(new StopIteration)) instead of
Allen Wirfs-Brock wrote:
Also, I find some of these questions seem simpler to reason about I think in
terms of an iterator with 'next', 'throw' and 'return' methods rather than a
generator and its various internal states.
The loop forms are external iteration
Christoph Martens wrote:
On the other hand that means typeof uint8 won't return a primitive
value, right? Meaning typeof uint8 should return object, so a
theoretical Polyfill (or binding in my case) should have the prototype
pointing to Object?
That's not decided, and polyfilling uint8 is
ES6 template string already solve the problem that this thread states,
without changing replace: http://gul.ly/149g
Rick
On Tue, Jul 29, 2014 at 2:24 PM, Alex Kit alex@atmajs.com wrote:
Would be nice to use something similar that mozilla now does: replace(string,
mix, ?flags)
that's the side effect of having fat arrow in the house, people need to
pray the parser/engine is smart enough to do not create and trash it every
time. all the time, during the loop or everywhere else is abused ... or,
you simply do what you said already, you reuse code and create the callback
On Tue, Jul 29, 2014 at 4:24 PM, Rick Waldron waldron.r...@gmail.com
wrote:
ES6 template string already solve the problem that this thread states,
without changing replace: http://gul.ly/149g
Sorry, I should've just included this in-line:
var func = function() {
var y = [ 52, '$'];
The Loader hook callbacks all have an API defined like:
Reflect.Loader.prototype.locate ( loadRequest )
My interpretation of this description was that the callback provider should
expect the same loadRequest object in to reappear during the load pipeline
and furthermore, this being JavaScript,
curious to know if `This is a simple ${func}` would have invoked
`func.toString()` for us implicitly ... will check specs
On Tue, Jul 29, 2014 at 4:32 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Tue, Jul 29, 2014 at 4:24 PM, Rick Waldron waldron.r...@gmail.com
wrote:
ES6 template
ES6 template string already solve the problem that this thread states, without
changing replace
with the link it was alright
The problem here is that a template string is the literal, that means you have
to hardcode it. But more interesting and more usual are dynamic
strings(variables): var x
Sorry for rising this subject again, but I am somewhat vexed about the
changed decision for the exception throwing when null is passed to the
for..of statement. I know, that my writing here wont change it now, but I
am a little bit uneasy about this dangerous precedent. So why it should not
throw
On Jul 29, 2014 5:47 AM, alawatthe alawat...@googlemail.com wrote:
Clear rules would also help in discussions like this one:
https://code.google.com/p/v8/issues/detail?id=3006
Background:
V8 implemented a new version of sin and cos, which is faster, but does
not have the precision many user
26 matches
Mail list logo
