Hi all,
Weighing in... First off, love the idea of Function#repeat.
Wonderfully simple and expressive.
As Tobie says, the goals when doing it should be to handle all of the
issues PE already handles, to reuse existing code, and to be
consistent with other API functions.
Some notes:
1. I'd
@TJ...
Your goals sound about right. Implicit in there, I think, is make it easy
to deprecate PE at some later date. At least, that's how I read it. :)
Re: #2 - Why not just use bind() to provide context? I've never been a fan
of overloading arguments with multiple interpretations. 'Gets
Hey Robert,
It's true, I was thinking in terms of deprecating PE at some
stage... :-)
Re #2: Using #bind at least doubles the call overhead, which I'm not a
fan of generally.
...have it throw $break!
Now that is a very smart idea.
--
T.J. Crowder
tj / crowder software / com
On Aug 27, 4:13
Food for thought:
1. We would like to completely decouple native and host objects in the
LANG section for version 1.7.
`setTimeout` and `setInterval` are host objects...
2. We're planning strict ES 5 compliance of enumerables for 1.7. that
implies removing $break.
Best,
Tobie
On Aug 27,
*blech* to ES5's enumerable stuff not having $break or similar
functionality. I've just read the forEach section of the draft spec
from a while back, and I'm not seeing a discussion of exception
handling. I haven't delved deep, though -- do you know offhand how
exceptions in the callback
Exceptions aren't eaten.
Good, so a $break-like mechanism is possible then, just moved out a
level.
-- T.J.
On Aug 27, 10:49 pm, Tobie Langel tobie.lan...@gmail.com wrote:
*blech* to ES5's enumerable stuff not having $break or similar
functionality. I've just read the forEach section of
How to stop it? arguments?
Stopping it is as easy as:
pe = foo.repeat();
pe.stop();
Passing arguments would require some simple currying:
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length 1) {
// not testsed but you get the idea
fn =
Tobie,
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length 1) {
// not testsed but you get the idea
fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
}
return new PeriodicalExecuter(fn, interval);
}
If sticking to the PE
Rick,
Maybe i'm missing how that revision works, but it appears to me that
your stop property doesn't actually stop the repeater. Your stop
returns before further execution happens, but the timeout ID for the
window still exists.
What am i missing?
-joe t.
On Jun 24, 12:20 pm, Rick Waldron
Note this last revision brings back a bit more of Robert's version, it's
more 50/50 now.
Rick
On Thu, Jun 25, 2009 at 12:53 PM, Rick Waldron waldron.r...@gmail.comwrote:
You're right... It appears i copied the source in a bit hastily. After
re-examining, I've revised again...
You're right... It appears i copied the source in a bit hastily. After
re-examining, I've revised again...
http://jsbin.com/ajoqu
Rick
On Thu, Jun 25, 2009 at 9:37 AM, joe t. thooke...@gmail.com wrote:
Rick,
Maybe i'm missing how that revision works, but it appears to me that
your stop
Thanks for the insight Tobie, definitely appreciated.
Function.prototype.repeat = function(interval) {
return new PeriodicalExecuter(this, interval);
}
How to stop it? arguments?
This may come to you twice, but this is slightly updated:
http://jsbin.com/opimu
This repeat() method def is
You might also want to look at the already existing
PeriodicalExecuter.
Any implementation of a Function#repeat API should take this in
account.
On Jun 24, 2:55 pm, joe t. thooke...@gmail.com wrote:
Only suggestion i can think of is that your method strongly implies a
requirement that
I can't say I'm a big fan of this. For several reasons.
First, it's just a cosmetic replacement for setInterval(myfunction
(...).bind(), ...) which simply isn't all that bad.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the
This is fantastic feedback - thanks!
On Wed, Jun 24, 2009 at 9:55 AM, Robert Kieffer bro...@gmail.com wrote:
I can't say I'm a big fan of this. For several reasons.
First, it's just a cosmetic replacement for setInterval(myfunction
(...).bind(), ...) which simply isn't all that bad.
I've subbed my implementation with your to do some use-case testing. I'll
report back anything of interest as I go along.
Rick
On Wed, Jun 24, 2009 at 10:49 AM, Rick Waldron waldron.r...@gmail.comwrote:
This is fantastic feedback - thanks!
On Wed, Jun 24, 2009 at 9:55 AM, Robert Kieffer
I made a few modifications to your version, allowing repeat() to behave like
delay() with regard to arguments
I've posted a demo here:
http://jsbin.com/ekone
All the output is to the firebug console... i've included fbug lite just in
case
Rick
On Wed, Jun 24, 2009 at 10:50 AM, Rick
Just to clarify the above: Prototype Core already contains a similar
functionality: PeriodicalExecuter. The API is different but the
functionality is the same.
I'd strongly suggest looking into combining both approaches if you
want your suggestion to be included in core and not just stay a
FWIW, PeriodicalExecuter has always struck me as a bit of a wart on
the Prototype API. The name and usage are awkward, and it's
functionality really feels like something that should just be a
Function extension, as we're seeing in this thread. I'm assuming it's
presence is mostly a legacy thing.
Tobie,
I had in fact looked into PeriodicalExecuter and to be perfectly honest,
with no offense intended, i think it's usage syntax is hideous which is what
led me to writing my own Function.prototype method instead, taking
inspiration from .delay()
It doesnt matter to me whether or not
Hi Rick, hi Robert.
Fully agree regarding PE. It does however handle issues a regular
setInterval doesn't (as you mentioned).
It's clearly an area which would need refinement, but that's better
done in a backwards compatible way.
Personally, I'd love to see PE implemented as a method of
21 matches
Mail list logo
