Note that the theoretical O(n) isn't always a good unit of measurement for
practical speed. Having to keep extra precision variables, or having extra
operations inside the loop will seriously slow down the computation, while
keeping it O(n).
I'd prefer that Math.sum(a, b, c) == a + b + c. In
There are no problems with reusability that I can think of as a result of the
internal state machine. The functions passed to `.then` are just plain
functions, so they are perfectly reusable.
I don't think there is a significant overhead to promises once properly
optimised. I don't see how
Apparently my proposal for adding the look-behind assertions to RegExp
has been in trouble. I would like to ask anyone for help.
The following story is what I know about the proposal after my previous
post:
I created a pull request for the proposal in July and sent an email to
Brendan Eich
On Sat, Oct 3, 2015 at 5:37 PM, 韩冬 wrote:
>
> This is exactly where i’m getting puzzled, suppose we have thread in
> javascript(or whatever to run different things on different cores),
> consider following code:
>
>
We don't have threads in JavaScript, and there is no
On Sat, Oct 3, 2015 at 6:00 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> well
>
> > In fact, oftentimes the way people code uses closures which tend to be
> more expensive than creating promises anyway.
>
> you pass "closures" to create a promise, a then and a catch, not sure
>
It'd be nice to add Function.prototype.partial, which is exactly like
`.bind` without the `this`-setting first argument.
Adding it would have benefits:
- `.bind(null, ...` is newbie confusing and ugly in functional code[1]
- `.bind(null, ...` is a very common idiom[2]
- `.partial` is intention
Sorry i messed up with the code format in previous mail, this one should work:
> There are no problems with reusability that I can think of as a result of the
> internal state machine. The functions passed to `.then` are just plain
> functions, so they are perfectly reusable.
Sorry, i should
> There are no problems with reusability that I can think of as a result of the
> internal state machine. The functions passed to `.then` are just plain
> functions, so they are perfectly reusable.
Sorry, i should be more clear about reusability i’m referring are not the
functions you passed,
On Thu, Oct 1, 2015 at 6:52 PM Eli Perelman wrote:
> Reviving this thread, doing any type of simple statistics is more verbose
> than it probably needs to be as calculating sums, averages, etc. makes most
> resort to Array reduction. I understand the need for methods such
I think his point was that in the functional programming way he is thinking
about, you don't care about `this` at all so you can shim `partial` like:
```js
Object.defineProperty(
Function.prototype,
'partial',
{
writable: true,
configurable: true,
value: function partial() {
for code sake, the dynamic should copy and push, not just push
```js
Object.defineProperty(
Function.prototype,
'partial',
{
writable: true,
configurable: true,
value: function partial() {
for (var f = this, a = [], i = 0; i < arguments.length; a[i] =
arguments[i++]);
(note, it couldn't be a direct proxy to `bind` because `bind(null)`
permanently sets the "this" value (ie, `(function () { return this
}).bind(null).call([])` will return null or the global object, not the
empty array. the polyfill would be a bit trickier, and couldn't use "bind"
under the hood
12 matches
Mail list logo