Re: [Prototype-core] Playing with Google's Closure Compiler and got a message for Prototype 1.7.0.0
Andrew, Richard
Not sure if this helps, but I figured it was worth the mention... jQuery no
longer uses GCC for min/compression... but when we did, we had the warn
level set to quiet:
https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7c3542ffd1b19257a8e5e#L0L104
Hopefully that's useful information :)
Rick
On Tue, May 17, 2011 at 1:53 PM, Andrew Dupont goo...@andrewdupont.netwrote:
I had to look it up, because that's part of Sizzle [1], but accessing that
property does have a side effect, apparently. It makes the `selected`
property work correctly when something is selected by default.
That strikes me as a spurious thing for GCC to warn about — you wouldn't
typically expect property access to have side effects, but with
getters/setters now in JavaScript, it'll become more and more common.
Cheers,
Andrew
[1] https://github.com/jquery/sizzle/blob/master/sizzle.js#L598
On May 17, 2011, at 11:24 AM, Richard Quadling wrote:
Hi.
Using Google Maps API with Prototype. Playing putting it into Google
Closure Compiler.
Got a message ...
Number of warnings: 1
JSC_USELESS_CODE: Suspicious code. This code lacks side-effects. Is
there a bug? at line 4437 character 3 in prototype.js
elem.parentNode.selectedIndex;
^
which is ...
filters: {
enabled: function(elem){
return elem.disabled === false elem.type !==
hidden;
},
disabled: function(elem){
return elem.disabled === true;
},
checked: function(elem){
return elem.checked === true;
},
selected: function(elem){
elem.parentNode.selectedIndex; // line
4437
return elem.selected === true;
},
parent: function(elem){
return !!elem.firstChild;
},
empty: function(elem){
return !elem.firstChild;
},
It looks like they are right? From what I know, that statement isn't
going to do anything.
To see this in action...
Go to http://closure-compiler.appspot.com/home and enter ...
// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// @output_file_name default.js
// @code_url
http://ajax.googleapis.com/ajax/libs/prototype/1.7.0.0/prototype.js
// @code_url
http://maps.google.com/maps/api/js?libraries=geometrysensor=false
// ==/ClosureCompiler==
// ADD YOUR CODE HERE
alert(1);
as the code to optimize.
Choose Simple from the list of optimizations.
Click Compile and then look at the warnings tab on the right hand side.
Regards,
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
Re: [Prototype-core] DOM Events Mutation event types
I've used all of the support Mutation Events with $(document).observe() without changing anything in Prototype. On Thu, Jan 14, 2010 at 7:23 AM, Allen Madsen bla...@gmail.com wrote: I wouldn't mind if this made it into core either. Allen Madsen http://www.allenmadsen.com On Tue, Jan 12, 2010 at 3:21 PM, matti matti.t.jarvi...@gmail.com wrote: Is there a reason why Prototypejs doesn't fire mutation events ( http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents-h3 ) as custom events (like dom:subtreemodified) when using Element.update and Element.insert? I know that browser support for those events are lacking but I'd believe that DOMSubtreeModified, DOMNodeInsertedIntoDocument and DOMAttrModified would be easy to implement as custom events (or simulated as such if browser has support for them) and could add value preventing memory leaks on AJAX heavy UIs. Point in all this would be that it would be easier to handle Event.stopObserving. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
Re: [Prototype-core] DOM Events Mutation event types
Supported* On Thu, Jan 14, 2010 at 12:12 PM, Rick Waldron waldron.r...@gmail.comwrote: I've used all of the support Mutation Events with $(document).observe() without changing anything in Prototype. On Thu, Jan 14, 2010 at 7:23 AM, Allen Madsen bla...@gmail.com wrote: I wouldn't mind if this made it into core either. Allen Madsen http://www.allenmadsen.com On Tue, Jan 12, 2010 at 3:21 PM, matti matti.t.jarvi...@gmail.comwrote: Is there a reason why Prototypejs doesn't fire mutation events ( http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents-h3 ) as custom events (like dom:subtreemodified) when using Element.update and Element.insert? I know that browser support for those events are lacking but I'd believe that DOMSubtreeModified, DOMNodeInsertedIntoDocument and DOMAttrModified would be easy to implement as custom events (or simulated as such if browser has support for them) and could add value preventing memory leaks on AJAX heavy UIs. Point in all this would be that it would be easier to handle Event.stopObserving. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Function.EMPTY and Function.K
On the subject of end developer confusion, I'd like to make a suggestion regarding the naming... Function.emptyFn Function.returnFn Because they say exactly what they are. This is how I've named (almost... $.function.emptyFn() and $.function.returnFn() ) the exact same functionality in the Pollen.JS library (for use within a new Worker() ) Rick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: A more efficient $super for Prototype 2
TJ...
I once woke up from a nap in the middle of a saturday and solved a silly
issue i was having with event bubbling/propagation... I had seen the
solution in code as the last thing before I woke up. I tried it... and it
worked. The point: never feel bad about waking up to code on the brain :)
Rick
On Sun, Sep 6, 2009 at 5:38 AM, T.J. Crowder t...@crowdersoftware.com wrote:
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works.
Ack! Sorry, too early in the morning, hadn't had enough coffee.
That does *not* work, because you always refer to the bottommost
subclass's nifty (this.nifty is always the bottommost function), so
you end up endlessly recursing. Wow that's an easy trap to fall into.
No, it's either use the function's name unadorned, or use
arguments.callee and pay the performance penalty. Personally, I
prefer using the function's name. :-)
-- T.J. :-)
On Sep 6, 8:48 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Allen,
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works. A named function's name is in
scope within the function:
function foo(bar) {
alert(typeof foo); // Alerts function
}
However, I was thinking about anonymous functions this morning while
waking up (pathetic, isn't it?) and realized that even if you don't
use a named function, you can avoid arguments.callee with exactly the
form you describe: this.nifty.$super.call(this, foo); I don't like
the repetition of this, but if you don't have time to switch
everything over to named functions (I'm thinking of retrofitting
efforts), it's a reasonable first step, and I assume (haven't tested
it yet) still gets speed gains over arguments.callee.
Will be posting a sample implementation (it's wonderfully simple, but
there are a couple of edge cases around dynamic updates of classes)
and tests ASAP, but I want to get some of the Prototype documentation
issues sorted out first (transferring the old doc to the new format
and updating), since that's more urgent.
-- T.J. :-)
On Sep 5, 2:46 pm, Allen Madsen bla...@gmail.com wrote:
var Thingy = Class.create({
nifty: function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
});
It just ignores the function name and complains that 'nifty' is not
defined. This works:
I think you need this.nifty.$super.call(this, foo);
Allen Madsenhttp://www.allenmadsen.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Node List?
If you're interested, I've actually built a bridge library called GenevaJS
that does exactly what you're looking for.
Keep in mind, it's not yet finished, but the core concept you're looking
for, things like:
$('collection').addClassName('classname');
Is there.
Yes... thats a single $... GenevaJS modifies the $ to behave like $$
(without breaking anything...ever)
http://genevajs.com
Rick
On Thu, Jul 30, 2009 at 2:43 PM, Ken Snyder kendsny...@gmail.com wrote:
Mike,
Yes, that type of class is quite helpful. Here is a concise implementation
of your idea: http://gist.github.com/158849
It could be improved a lot. For example, you could alter
Element.addMethods() to also add methods to the NodeList object.
This type of class is probably appropriate for a Scripteka submission, but
there may be other implementations already there. Feel free to use my code
however you like and submit it if you want.
Best regards,
Ken Snyder
On Mon, Jul 27, 2009 at 2:53 PM, Mike Rumble mike.rum...@gmail.comwrote:
A developer that's recently joined my team is new to Prototype and is
finding himself trying to do things in a jQuery-ish way, for example:
$$('.panel').addClassName('red').addClassName('blue');
I explained the differences between the Prototype and JQuery ways of
doing things, and demonstrated that the same result could be achieved
using Prototype with not a great deal more code:
$$('.panel').invoke('addClassName', 'red').invoke('addClassName',
'blue');
At the same time I noticed the NodeList present in the BBC's new Glow
library (see here:
http://www.bbc.co.uk/glow/docs/1.5/api/glow.dom.nodelist.shtml
), and wondered whether Prototype could benefit of a similar module to
allow the element methods to be invoked on a collection of DOM nodes
(the return of $$) and chained together jQuery-style.
A real basic implementation could look something like this, only less
lame
var NodeList = Class.create(Enumerable, {
initialize : function(elements){
this.elements = elements;
},
_each : function(iterator){
this.elements.each(iterator);
},
item : function(i){
return this.elements[i];
}
addClassName : function(className){
this.elements.invoke('addClassName', className);
return this;
}
// More methods here
});
I don't think Prototype needs to make itself like jQuery, and I'm not
looking to start that debate here. I am however interested to hear if
anyone thinks there is any value in this approach, or indeed if not.
Personally I think it would do well to make Prototype more accessible
to newcomers.
Thanks,
Mike.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Node List?
To add a little more information... GenevaJS dynamically redefines all of
prototype's Element methods to behave like Enumerable methods and comes with
about 80% of jQuery's methods...
On Thu, Jul 30, 2009 at 3:04 PM, Rick Waldron waldron.r...@gmail.comwrote:
If you're interested, I've actually built a bridge library called
GenevaJS that does exactly what you're looking for.
Keep in mind, it's not yet finished, but the core concept you're looking
for, things like:
$('collection').addClassName('classname');
Is there.
Yes... thats a single $... GenevaJS modifies the $ to behave like $$
(without breaking anything...ever)
http://genevajs.com
Rick
On Thu, Jul 30, 2009 at 2:43 PM, Ken Snyder kendsny...@gmail.com wrote:
Mike,
Yes, that type of class is quite helpful. Here is a concise implementation
of your idea: http://gist.github.com/158849
It could be improved a lot. For example, you could alter
Element.addMethods() to also add methods to the NodeList object.
This type of class is probably appropriate for a Scripteka submission, but
there may be other implementations already there. Feel free to use my code
however you like and submit it if you want.
Best regards,
Ken Snyder
On Mon, Jul 27, 2009 at 2:53 PM, Mike Rumble mike.rum...@gmail.comwrote:
A developer that's recently joined my team is new to Prototype and is
finding himself trying to do things in a jQuery-ish way, for example:
$$('.panel').addClassName('red').addClassName('blue');
I explained the differences between the Prototype and JQuery ways of
doing things, and demonstrated that the same result could be achieved
using Prototype with not a great deal more code:
$$('.panel').invoke('addClassName', 'red').invoke('addClassName',
'blue');
At the same time I noticed the NodeList present in the BBC's new Glow
library (see here:
http://www.bbc.co.uk/glow/docs/1.5/api/glow.dom.nodelist.shtml
), and wondered whether Prototype could benefit of a similar module to
allow the element methods to be invoked on a collection of DOM nodes
(the return of $$) and chained together jQuery-style.
A real basic implementation could look something like this, only less
lame
var NodeList = Class.create(Enumerable, {
initialize : function(elements){
this.elements = elements;
},
_each : function(iterator){
this.elements.each(iterator);
},
item : function(i){
return this.elements[i];
}
addClassName : function(className){
this.elements.invoke('addClassName', className);
return this;
}
// More methods here
});
I don't think Prototype needs to make itself like jQuery, and I'm not
looking to start that debate here. I am however interested to hear if
anyone thinks there is any value in this approach, or indeed if not.
Personally I think it would do well to make Prototype more accessible
to newcomers.
Thanks,
Mike.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...]) -- Revised from Robert's version
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...
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 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 waldron.r...@gmail.com wrote:
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 Waldron waldron.r...@gmail.com
wrote:
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 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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems
to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees
you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling
the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater,
delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this...
have
been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval =
args.shift()
*
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...]) -- Revised from Robert's version
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 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 waldron.r...@gmail.com wrote:
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 Waldron waldron.r...@gmail.com
wrote:
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.com
wrote:
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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees
you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling
the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this...
have
been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval =
args.shift()
*
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval
instead of
setTimeout. One thing I intend to add
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
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 775Bytes, accepts arguments like delay/defer,
uses setTimeout (returns initial setTimeout index) and has a stopping
mechanism.
Rick
On Wed, Jun 24, 2009 at 10:04 PM, Tobie Langel tobie.lan...@gmail.comwrote:
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 Function
instances.
So since this is the core mailing list, I'm trying to give directions
on how it could be best implemented given legacy constraints and
consistency with the rest of the API.
Clearly, consistency with Function#defer and Function#delay would
imply returning a setInterval index. Unfortunately, since setTimeout
is used instead of setInterval, this isn't possible.
Maybe the simplest solution would be to make Function#repeat return an
instance of PE. Implementation would then be roughly:
Function.prototype.repeat = function(interval) {
return new PeriodicalExecuter(this, interval);
}
Note that in that case, modifying Function#delay and Function#defer to
return a PE-like object instance with a stop method would make more
sense API wise, but at the expense of a larger memory footprint and
backwards compatibility.
As you can see, making the right choice isn't simple.
Best,
Tobie
On Jun 24, 11:28 pm, Rick Waldron waldron.r...@gmail.com wrote:
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 .repeat() makes it into the
prototype
core - I will always have it at my disposal, I simply wanted to share the
concept with the group.
I think everything I've said sounds like I'm in a bad mood, sorry about
that! :D
Rick
On Wed, Jun 24, 2009 at 12:53 PM, Tobie Langel tobie.lan...@gmail.com
wrote:
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 thread
in the mailing list. :)
Best,
Tobie
On Jun 24, 4:50 pm, Rick Waldron waldron.r...@gmail.com wrote:
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.com
wrote:
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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked
function
takes longer than the delay to execute. In particular, this seems
to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use
a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals,
but
that type of accuracy is rarely important. Instead, it guarantees
you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling
the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or
delay==0)
// Create setTimeout-based invoker
var _method
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this... have been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval = args.shift() *
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval instead
of
setTimeout. One thing I intend to add is support for clearInterval,
however
I figured I'd at least bring it up here first. I've never
proposed/contributed here before (i'm a lurker of the list :D ) - any
guidance is appreciated.
Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
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 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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this... have
been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval = args.shift() *
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval instead
of
setTimeout. One thing I intend to add is support for clearInterval,
however
I figured I'd at least bring it up here first. I've never
proposed/contributed here before (i'm a lurker of the list :D ) - any
guidance is appreciated.
Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...]) -- Revised from Robert's version
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 Waldron waldron.r...@gmail.comwrote:
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 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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this... have
been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval = args.shift()
*
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval
instead of
setTimeout. One thing I intend to add is support for clearInterval,
however
I figured I'd at least bring it up here first. I've never
proposed/contributed here before (i'm a lurker of the list :D ) - any
guidance is appreciated.
Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
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 .repeat() makes it into the prototype
core - I will always have it at my disposal, I simply wanted to share the
concept with the group.
I think everything I've said sounds like I'm in a bad mood, sorry about
that! :D
Rick
On Wed, Jun 24, 2009 at 12:53 PM, Tobie Langel tobie.lan...@gmail.comwrote:
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 thread
in the mailing list. :)
Best,
Tobie
On Jun 24, 4:50 pm, Rick Waldron waldron.r...@gmail.com wrote:
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.com
wrote:
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.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this... have
been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval =
args.shift() *
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical
[Prototype-core] Re: writeAttribute 'style' in IE 7
$(elParent).readAttribute('style')
is elParent a var of an extended element? my first guess would be that it is..
if it is.. try:
elParent.readAttribute('style')
if its not... try:
$('elParent').readAttribute('style')
same with:
el.writeAttribute(
so... put together:
el.writeAttribute('style', elParent.readAttribute('style'));
Also, i'd replace the methods...
el.setAttribute('style', elParent.getAttribute('style'));
I just tried this in IE 7 and it worked.
readAttribute and writeAttribute have issues in IE7...
On Thu, Apr 30, 2009 at 10:13 AM, bazikch bazik...@gmail.com wrote:
Hello,
I'm trying to do the following:
$(el).writeAttribute('style', $(elParent).readAttribute('style'));
Everything is going fine until I try to clone the el position
(#clonePosition).
IE throws the error: 'style' is null or not an object on line 2271
(#Element.Methods.getStyle).
The strange thing is when I look at the DOM, the el element has an
_undefined_ attribute with the previous copied style. IMHO this lead
to the mentionned error.
Is this a bug or the _standard_ behaviour of IE?
Thanks in advance.
[Prototype version 1.6.0.2]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
