On Mar 15, 5:49 pm, Tobie Langel tobie.lan...@gmail.com wrote:
Thanks.
I'd like the refactoring to include all Function.prototype methods,
not just bind, so we have a clean and coherent src code.
Best,
Tobie
I've just created a ticket that includes a patch to as much of the
function.js
Here's a thought: bindAsEventListener() is basically bind() where a
certain number of leading args are expected at call-time and the rest
are provided at bind-time. (Unless you use it to create DOM0-style
handlers on IE; Don't Do That, this is 2009.) So perhaps the symbol
bindAsEventListener
On Mar 14, 8:24 am, kangax kan...@gmail.com wrote:
Why not combine two?
...
function() {
if (arguments.length) {
var ll = arguments.length;
args.length = l + ll;
while (ll--) {
args[l+ll] = arguments[ll];
}
}
return fn.apply(context, args);}
}
This
We've discussed deprecating bindAsEventListener about half a dozen
times already, and it just doesn't make sense, for the reasons
expressed above. So there's no point in discussing this further. I
suggest this be clarified in the documentation.
Regarding partial application in
What this all means is that these 2 expressions are functionally
identical (considering that they are called from within the same
execution context):
myElement.observe('click', onClick.bind(this));
myElement.observe('click', onClick.bindAsEventListener(this));
FWIW, this was not always
So, (sorry not to capture all this in a single post)...
To re-iterate, Kangax, you _should_ be using .bindAsEventListener in your
first case if you want to guarantee backwards X-browser support.
On Sun, Mar 15, 2009 at 9:52 AM, Ryan Gahl ryan.g...@gmail.com wrote:
On Sun, Mar 15, 2009 at
On Mar 15, 9:06 am, Robert Kieffer bro...@gmail.com wrote:
On Mar 14, 8:24 am, kangax kan...@gmail.com wrote:
Why not combine two?
...
function() {
if (arguments.length) {
var ll = arguments.length;
args.length = l + ll;
while (ll--) {
args[l+ll] =
On Mar 15, 10:35 am, Tobie Langel tobie.lan...@gmail.com wrote:
[...]
The difficulty of abstracting your solution comes from the need for
the bound function to keep a reference to the original length of the
array so a to reset it before passing it to the original function.
I suspect that the
On Mar 15, 10:54 am, Ryan Gahl ryan.g...@gmail.com wrote:
So, (sorry not to capture all this in a single post)...
To re-iterate, Kangax, you _should_ be using .bindAsEventListener in your
first case if you want to guarantee backwards X-browser support.
What do you mean by backwards X-browser
Isn't that what your internal (used with `Function.prototype`
extensions) `update` does?
Precisely.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send
To re-iterate, Kangax, you _should_ be using .bindAsEventListener in your
first case if you want to guarantee backwards X-browser support.
No. The only use case for bindAsEventListener other than partial
application is for inline event handlers in IE:
var myObj = {
doSomething:
What do you mean by backwards X-browser support?
Come on dude, really? You didn't get what I was saying there? I meant cross
browser support, including older browsers. Even if I was wrong on the
details, I thought that phrase was fairly self explanatory... guess not.
Just like I said, IE
Tobie:
...it just doesn't make sense
You may think that it doesn't, but that's an opinion, not received
wisdom from on high. If you want to keep supporting DOM0 handlers
with it, fine, say that.
Regarding partial application in Function.prototype.bind, that's been
part of Prototype for a
Sorry T.J. if my last comment came across as agressive.
Just to clarify:
You may think that it doesn't, but that's an opinion, not received
wisdom from on high. If you want to keep supporting DOM0 handlers
with it, fine, say that.
Deprecating a useful API without replacing it by something
Gotcha, sorry for the misunderstanding.
Deprecating a useful API without replacing it by something at least as
good is not a good practice imho.
We do need that separate thread. (There was more to this paragraph,
but the first sentence kinda rendered the rest of it OT!!)
-- T.J.
On Mar 15,
Thanks.
I'd like the refactoring to include all Function.prototype methods,
not just bind, so we have a clean and coherent src code.
Best,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype
@Tobie: Thanks! And wow, the February language is _much_ more
explicit.
@Richard:
But when you call a function returned by bind(), how often are you
passing arguments?
Ah, okay. And the answer is, of course, nearly always.
-- T.J.
On Mar 13, 11:44 pm, Tobie Langel tobie.lan...@gmail.com
On Mar 13, 4:33 pm, Tobie Langel tobie.lan...@gmail.com wrote:
It's this latter case where having the args array cached provides
significant performance benefit, which I would argue is worth doing,
even if it slightly lessens the performance of someFunc() with no
arguments. That's the
... and it's probably worth pointing, again, to my updated performance
data on this page:
http://www.broofa.com/blog/2009/03/prototype-bind-performance/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype
On Mar 13, 4:33 pm, Tobie Langel tobie.lan...@gmail.com wrote:
It's this latter case where having the args array cached provides
significant performance benefit, which I would argue is worth doing,
even if it slightly lessens the performance of someFunc() with no
arguments. That's the
On Mar 14, 9:15 am, Robert Kieffer bro...@gmail.com wrote:
On Mar 13, 4:33 pm, Tobie Langel tobie.lan...@gmail.com wrote:
It's this latter case where having the args array cached provides
significant performance benefit, which I would argue is worth doing,
even if it slightly lessens
I'd like to see how we can combine all of this elegantly with
bindAsEventListener and curry.
Event if the cost for this is an extra function call.
On Mar 14, 4:24 pm, kangax kan...@gmail.com wrote:
On Mar 14, 9:15 am, Robert Kieffer bro...@gmail.com wrote:
On Mar 13, 4:33 pm, Tobie Langel
On Mar 14, 11:43 am, Tobie Langel tobie.lan...@gmail.com wrote:
I'd like to see how we can combine all of this elegantly with
bindAsEventListener and curry.
I personally don't understand the need for `bindAsEventListener` at
all. It's the most misunderstood method in Prototype. Its scope of
Right. And that warrants clear(er) documentation and not deprecation,
as there is no other way to handle partial application in event
handlers.
On Mar 14, 7:10 pm, kangax kan...@gmail.com wrote:
On Mar 14, 11:43 am, Tobie Langel tobie.lan...@gmail.com wrote:
I'd like to see how we can
That's specified more clearly in the Es 3.1 draft, actually.
I was quoting the 3.1 draft from November (which had no substantive
changes from the 262 standard); do you have a link for a newer one?
And agreed, it would very weird indeed -- weird and, from an
engineering standpoint, JPW (Just
...I'd say it's
a tossup as to how often a bound function will/won't be passed
arguments
H. That would be worth checking. I almost never use bind() with
arguments other than the context; in fact, I don't recall the last
time I did.
--
T.J. Crowder
tj / crowder software / com
On Mar 13, 12:12 am, T.J. Crowder t...@crowdersoftware.com wrote:
...I'd say it's
a tossup as to how often a bound function will/won't be passed
arguments
H. That would be worth checking. I almost never use bind() with
arguments other than the context; in fact, I don't recall
It's this latter case where having the args array cached provides
significant performance benefit, which I would argue is worth doing,
even if it slightly lessens the performance of someFunc() with no
arguments. That's the tradeoff we're talking about.
I don't think that tradeoff is
On Mar 13, 8:08 am, T.J. Crowder t...@crowdersoftware.com wrote:
I was quoting the 3.1 draft from November (which had no substantive
changes from the 262 standard); do you have a link for a newer one?
T.J.: You'll find the drafts here:
When Tobie was rewriting functional extensions, I proposed using
approach similar to `bind3` [1], but for whatever reason it never
happened : )
Probably because no one ever wrote a patch for it ;)
--~--~-~--~~~---~--~~
You received this message because you are
It seems to me the spec on the first behavior is a bit less clear
(Section 15.3.4.3): If argArray is either an array or an arguments
object, the function is passed the (ToUint32(argArray.length))
arguments argArray[0], argArray[1], ..., argArray[ToUint32
(argArray.length)–1]. That doesn't
@Kangax: That's definitely a nice improvement! I've updated my post to
include your method as well as an Improved method that adds my trick
for reusing the args array. The improved version is a little slower
when you call the bound function w/out args, but is significantly
faster (on most
[Wow, wasn't expecting such a barrage of (great) responses! (I get
this list in digest mode, so find myself scrambling to catch up
here.)]
That tends to happen here :)
Rob, those are some VERY impressive numbers you put up in that blog post. I
absolutely have to avoid the mailing list
If we recast our example to use a named function for the handler:
function init() {
var container;
container = $('container');
hookUpHideables(container);
container.show();
function hookUpHideables(p) {
p.select('.hideable').invoke('observe', 'click',
Hi,
That's true, but your example does not use .bind(), therefore I don't
really see how it pertains to the discussion.
I was addressing your question (the one I quoted), not the bind
discussion.
When you .bind(), you are
passing the the function to bind, along with it's context and all
Your results look impressive indeed.
However, I'd like to ponder code source readability and
maintainability with performance (which was the main goal of the
recent changes).
Could you maybe benchmark this:
function bind(context) {
var __method = this, args;
if
Has that been tested with deferral?
Ryan Gahl
CEO
Nth Penguin, LLC
http://www.nthpenguin.com
--
Inquire: 1-920-574-2218
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
On Wed, Mar 11, 2009 at 1:13 PM, Tobie Langel tobie.lan...@gmail.comwrote:
Actually,
@Tobie: [*Evil Cackle*]... You just now noticed that, did you?
Yeah, it's a nice little trick. And, yes, it does look a little
fishy, but I couldn't think of any reason why it wouldn't work.
I've updated the blog post to include your implementation in the
tests. (BTW, please note that if
*dooh* sorry - shoulda just stuck that code in a Pastie, like so:
http://pastie.org/412930
FWIW, I just collected some stats on our code to determine what %'age
of cases are binding arguments .vs. just binding an object. It looks
like it's ~98.5% (2170 of 2200 calls to bind pass a single object
2009/3/10 Robert Kieffer bro...@gmail.com:
*dooh* sorry - shoulda just stuck that code in a Pastie, like so:
http://pastie.org/412930
FWIW, I just collected some stats on our code to determine what %'age
of cases are binding arguments .vs. just binding an object. It looks
like it's ~98.5%
Hi,
On the face of it, I like the thought of skipping the arguments prep
in the no-args case, but have you done any profiling to be sure that
it really has a measurable benefit? Same question on inlining the per-
call arguments concatenation... Without a solid, measurable benefit,
I'd avoid
On Mar 10, 12:41 pm, Robert Kieffer bro...@gmail.com wrote:
[...]
- bind() is so ubiquitous for us that performance is a top priority.
Your version is still slower than it could be ; )
`$A`, `shift`, `apply` - all of those slow things down for no good
reason.
Take a look at
Robert, have you looked at the implementation in trunk ?
I rewrote most of it not long ago after serious benchmarking and
taking into consideration smart(er) memory management.
This kind of discussion belongs ont the core mailing list BTW, to make
sure no one misses it!
Best,
Tobie
On Mar
I won't speak to your .bind() mods as I've not reviewed them, but in
general, for the majority case of simply binding the context of a function
to an object in order to fix the this keyword within the function, it is
ALWAYS just easier and MUCH MUCH faster to early bind to a variable
outside the
I do agree there are just times when .bind() is called for, but I am fairly
certain the majority of people WAY overuse it.
+1 to that, where you're defining the function inline. Where you're
not, while this may be faster:
var self = this;
handler = function() {
Function.prototype.bind() is making it's way into ES 3.1. IT will be
interesting to see it's performance once it's native.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to
On Mar 10, 3:27 pm, T.J. Crowder t...@crowdersoftware.com wrote:
I do agree there are just times when .bind() is called for, but I am fairly
certain the majority of people WAY overuse it.
+1 to that, where you're defining the function inline. Where you're
not, while this may be faster:
Kangax...
2) Non-bound event handler is faster at run time, as it accesses
`onClick` from the proper object directly, but presumably consumes
more memory (due to extra closure, created during function expression
evaluation)
There is no extra closure because .bind() creates a closure anyway
I guess what I wanted to say is that a function created with
Prototype's `bind` (internally) has a predictable closure - the one
that's got formed when a function was declared. And it is declared by
Prototype, inside a very slim scope (self-executing function,
surrounding
49 matches
Mail list logo
