Brendan Eich bren...@mozilla.com wrote:
We already have good motivation for :: anyway, as sugar for bind. This
gives relief to the OO side of the expression problem trade-off by allowing
lexical bindings to be composed with method calls -- beautiful. No third
scope axis / lookup parameter!
Yeah,
Le 14/10/2013 23:25, Brendan Eich a écrit :
Jorge Chamorro wrote:
The only work around for that is making as few requests as possible.
+∞, +§, and beyond.
This is deeply true, and a hot topic with browser/network-stack
engineers right now.
It ought to be with software engineers as well and
Le 14/10/2013 23:20, Jorge Chamorro a écrit :
On 14/10/2013, at 22:11, David Bruant wrote:
You already can with inlining, can't you?
Yes and no:
-It's much more complicated than pre zipping a bunch of files and adding a ref
attribute.
-It requires additional logic at the server side, and
On 14 October 2013 22:10, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote:
But there were design issues too. ... user confusion or complexity remains
an objection.
Yes! This is the thing that bothers me most right now about scoped extension
methods. Introducing additional syntax to the
On Tue, Oct 15, 2013 at 12:50 PM, Andreas Rossberg rossb...@google.com
wrote:
Arguably, the _syntactic_ complexity is not huge. It is almost benign,
compared to the _semantic_ complexity.
Agreed. I have a bit of a problem articulating my thoughts clearly through
this medium being new. The
On 15 October 2013 03:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I still don't get why so many JS programmer with a FP orientation want to do
things with the |this| binding. |this| is for us OO geeks, if you are doing
FP you don't need it.
Well, 'this' comes up because you cannot
On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg rossb...@google.comwrote:
On 15 October 2013 03:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I still don't get why so many JS programmer with a FP orientation want
to do things with the |this| binding. |this| is for us OO geeks, if
On Tue, Oct 15, 2013 at 3:45 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Brendan Eich bren...@mozilla.com wrote:
We already have good motivation for :: anyway, as sugar for bind. This
gives relief to the OO side of the expression problem trade-off by allowing
lexical bindings to
On Oct 15, 2013, at 6:40 AM, Mark S. Miller wrote:
On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg rossb...@google.com wrote:
On 15 October 2013 03:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I still don't get why so many JS programmer with a FP orientation want to
do
On Tue, Oct 15, 2013 at 8:51 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Oct 15, 2013, at 6:40 AM, Mark S. Miller wrote:
On Tue, Oct 15, 2013 at 3:39 AM, Andreas Rossberg rossb...@google.comwrote:
On 15 October 2013 03:09, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I
On Oct 15, 2013, at 7:22 AM, Russell Leggett wrote:
If we didn't have :: (which we don't now), I think people will continue to
simply use functions like what underscore does. Personally, I'm ok with that.
If I want to have unscoped extensions and live with the consequences - I will
be
On Tue, Oct 15, 2013 at 11:59 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Oct 15, 2013, at 7:22 AM, Russell Leggett wrote:
If we didn't have :: (which we don't now), I think people will continue
to simply use functions like what underscore does. Personally, I'm ok with
that. If
First of all interesting analogy and read.
On Tue, Oct 15, 2013 at 5:22 PM, Russell Leggett russell.legg...@gmail.com
wrote:
I don't think that the scoped extensions you want are going to happen. I
used to like the idea of something like that, but I think it will cause a
lot more confusion than
If we didn't have :: (which we don't now), I think people will continue
to simply use functions like what underscore does. Personally, I'm ok with
that
I think using stuff like _.shuffle([1,2,3,4,5]) is not as nice and worse
than [1,2,3,4,5].shuffle() . Especially in a more functional
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15, 2013 12:45 AM
Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote:
We already have good motivation for :: anyway, as sugar for bind.
This gives relief to the OO side of the expression problem trade-off
by allowing
On Oct 15, 2013, at 9:44 AM, Benjamin (Inglor) Gruenbaum wrote:
...
The big issue I see here is chaining.
`_.reduce(_.map(_.filter([1,2,3,4,5],x=x%2 === 0),x=2*x),(x,y)=x+y)`
Is a lot less readable than
`[1,2,3,4,5].filter(x=x%2===0).map(x=2*x).reduce((x,y)=x+y))`
The big issue I see here is chaining.
`_.reduce(_.map(_.filter([1,2,3,4,5],x=x%2 === 0),x=2*x),(x,y)=x+y)`
Is a lot less readable than
`[1,2,3,4,5].filter(x=x%2===0).map(x=2*x).reduce((x,y)=x+y))`
P.S. This really doesn't look too shabby to me:
import {reduce,map,filter} from
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
October 14, 2013 6:09 PM
Speaking from the perspective of someone whose probably has permanent
OO brain damage, it doesn't do a lot for me.
The reason I invoke a method on an object is because I want to do
polymorphic dispatch on the method
Russell Leggett wrote:
The big issue I see here is chaining.
`_.reduce(_.map(_.filter([1,2,3,4,5],x=x%2 ===
0),x=2*x),(x,y)=x+y)`
Is a lot less readable than
`[1,2,3,4,5].filter(x=x%2===0).map(x=2*x).reduce((x,y)=x+y))`
P.S. This
Using your proposed underscore2 (OO-underscore?) with :: is no more
verbose than underscore.js (underscore1), and it has the chaining not
inside-out-composing win some may prefer.
I'm glad you noticed the 2. Perhaps oonderscore? :)
We should not argue only about taste, and bind (::) has a
Wait, I think maybe I did not understand what you meant before.
Are we talking about using `::` for infixing the first parameter of the
function? As in `func(a,b,c)` being the same as `a::func(b,c)` ?
Would that let us do `[1,2,3,4,5]::_.reduce(x=x%2 ===
0)::_.map(x=2*x)::._.reduce(x,y) =
On Tue, Oct 15, 2013 at 4:28 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Wait, I think maybe I did not understand what you meant before.
Are we talking about using `::` for infixing the first parameter of the
function? As in `func(a,b,c)` being the same as `a::func(b,c)` ?
Not
I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_ means
`b(a,x_1,...,x_n)` I think it might be a good solution to the chaining
problem.
I think the `.constructor` proposal as well as being able to do `::`
completely eliminates the need for extension methods in this regard. It
On Mon, Oct 14, 2013 at 8:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Oct 14, 2013, at 4:21 PM, Andrea Giammarchi wrote:
my last memories on the topic are these:
```javascript
var obj = JSON.parse('{__proto__:[]}');
obj instanceof Array; // false
obj.__proto__
Thanks, this clarifies things (the difference between having `this` and a
first argument is really not that big here at all imo and converting
between them two is easy).
What is your ideal SOE form? Because my guess is that I can get it darn
close with ::
It does seem a lot simpler than actual
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here (why would it not invoke the setter?)
On Wed, Oct 16, 2013 at 12:04 AM, Dean Landolt d...@deanlandolt.com wrote:
On Oct 15, 2013, at 2:10 PM, Benjamin (Inglor) Gruenbaum wrote:
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here (why would it not invoke the setter?)
Benjamin (Inglor) Gruenbaum wrote:
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here (why would it not invoke the setter?)
Allen confirmed, but just to be clear,
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15, 2013 2:00 PM
I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_
means `b(a,x_1,...,x_n)`
No, rather: `b.call(a, x_1, ..., x_n)` but with the original
Function.prototype.call (not any shadowing b.call).
I think
On Tue, Oct 15, 2013 at 5:50 PM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum wrote:
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here
On Oct 15, 2013, at 3:19 PM, Dean Landolt wrote:
So just to be clear, the only way to add a __proto__ property to an existing
object is with Object.defineProperty?
Object.mixin(obj, {[__proto__]:42});
Allen
___
es-discuss mailing list
not if you parsed that object via `JSON.parse('{__proto__:[]}')`
in this case is the equivalent of that operation through
`Object.defineProperty({}, '__proto__', {enumerable: true, writable: true,
configurable: true})` so that `obj.__proto__` will result into property
assignment and no setter
oh, that's cute :D
too bad I cannot shim/polyfill that in my `Object.mixin` module.
I would simply *red-flag* it and discourage the usage of `__proto__`
everywhere is possible (uhm wait ... I've already done that in the past,
never mind ... )
Happy `__dunder__` Everybody,
Cheers
On Tue,
wait ... what ?
On Tue, Oct 15, 2013 at 2:00 PM, Russell Leggett
russell.legg...@gmail.comwrote:
obj::fun(a,b) is not the same as fun(obj,a,b). Its fun.call(obj,a,b).
isn't this basically the equivalent of obj-fun then ? (yes, the other
arrow that was an arrow too far)
Thanks for
uhm, never mind, I got it now. Borrowing functions avoiding call/apply
looks good.
Best Regards
On Tue, Oct 15, 2013 at 4:17 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
wait ... what ?
On Tue, Oct 15, 2013 at 2:00 PM, Russell Leggett
russell.legg...@gmail.com wrote:
On Wed, Oct 16, 2013 at 1:04 AM, Brendan Eich bren...@mozilla.com wrote:
No, rather: `b.call(a, x_1, ..., x_n)` but with the original
Function.prototype.call (not any shadowing b.call).
Right, Russell clarified `::` to me and sent a link to the wiki (always
good!). Thanks.
I don't see purr on
36 matches
Mail list logo
