On 12/9/06, Martin Bialasinski <[EMAIL PROTECTED]> wrote:
>
> On 12/9/06, Peter Michaux <[EMAIL PROTECTED]> wrote:
>
> > I think el for element, hz for frequency, cb for callback, nv for new
> > value, and lv for last value are not extreme abbreviations.
>
> hz cb nv lv?
"hz" should have been "p" since this is period not frequency. The
university should shoot me and take away my Physics degree.
> Are you fucking kidding me?
No I'm not kidding and I'm also not swearing on a public list.
> We have the year 2006, not
> 1981 last time I checked!
But we are still distributing the code every time it needs to be used
so short without being ridiculous is better. Ridiculous would have
been five variables named a, b, c, d, e.
> > less code for the Prototype community to maintain.
>
> This is a maintenance nightmare!
It is far from nightmare. It is a small function with only a few
variables. I imagine you and i both have used "i" as the index of a
for loop before and probably a for loop with more content than this
function.
> And I remember you were all in rage
> about Prototype code to be difficult to understand for outsiders and
> now you propose a change to hz cb nv lv?
So Prototype made the decision to have a cryptic API and long-named,
short-lived local variables. Seems like the wrong way around to me.
Save the bandwidth for the API where outsiders interact with the
library.
> We should do this throughout
> the whole code, I am sure this will be all appreciated by anyone
> browsing the files.
The author written inline documentation will make it abundantly clear
what these short-lived identifiers mean.
> > If I've missed something here then that changes everything.
>
> getValue() is there for a reason. element.value !== lastvalue can not
> be used for checkboxes, radio controls and selects.
The default form element observer cannot handle this case and the
developer will have to subclass the abstract timed observer to handle
it. This code to subclass will be larger than the code to write a
completely custom, stand alone observer. This was my point.
> > However without retaining the value returned by setInterval() I can't
> > see that much can be manipulated after the observer starts.
> > You could
> > play weird tricks like changing the callback function but I doubt
> > anyone does that and it wouldn't fall under the 80/20 rule.
>
> How about patching it to save the interval ID and implement stop()?
> If there is not already a patch for this in Trac.
This could be added simply with the word "return" in my example.
> > Note also that in the Prototype code
> >
> > if (this.lastValue != value) {
> >
> > should probably be
> >
> > if (this.lastValue !== value) {
> >
> > because both 0 and the empty string '' typecast to false and so 0!=''
> > returns false.
>
> This is true.
I think you are correct in your other post that this is not supposed
to matter. However if a user provides the getValue() function then
they might be returning strange things to be used as value. I think
this is a good place for the extra equals sign character.
> > Note also that a semicolon at the end of this line looks like it would
> > make the observer section minimizable
>
> True again, but Thomas is not interested in that thing
I'm sure some users would appreciate saving about 50% bandwidth on
serving minimized Prototype on their hosting accounts. A couple tweaks
in the Prototype code would make it possible to use jsmin.
Peter
-------
http://forkjavascript.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
