Rails spinoffs - Dec 2006 - Shrinking Prototype's timed form observer code

Hello Augmenters,

(lighten up! ;-) )


[post order restored]
On 12/4/06, Thomas Fuchs <t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org>
wrote:
> Am 01.12.2006 um 19:15 schrieb Mislav:
>
> > Just don''t whine - make it work.
> > (And contribute.)
>
> Exactly.
Ok. Here''s a suggestion.

Prototype''s abstract timed observer code looks a little bulky.

Here is my implementation of a stand alone form input observer. I
think el for element, hz for frequency, cb for callback, nv for new
value, and lv for last value are not extreme abbreviations.

Form.Element.Observer = function(el, hz, cb) {
  el=$(el);
  var lv; // optionally could be  var lv = el.value;  or  var lv =
'''';
  setInterval(function() {
                 var nv = el.value;
                 if (nv !== lv) {
                   cb(el, nv);
                   lv = nv;
                 }
               },
               hz*1e3);
};

Below is the above code minimized.

Form.Element.Observer=function(el,hz,cb){el=$(el);var
lv;setInterval(function(){var
nv=el.value;if(nv!==lv){cb(el,nv);lv=nv;}},hz*1e3);};


Below is the code in Prototype necessary just to extend the existing
bulk of the abstract timed observer.

Form.Element.Observer=Class.create();Form.Element.Observer.prototype=Object.extend(new
Abstract.TimedObserver(),{getValue:function(){return
Form.Element.getValue(this.element);}});


Note that my code to implement an entire form element observer is
shorter than the code to extend the abstract timed observer even if
getValue and element are abbreviated to two letters. So Prototype''s
use of object inheritance is encouraging bulkier code and there is the
overhead of the abstract observer. Although I didn''t make a
performance test, I''m quite sure the shorter version will also run
faster because there are less function calls and object property
lookups.

Note that in the shorter version there is no need for the for the
complexity of Class.create() and Object.extend(). And to start a timed
observer a new object doesn''t have to be instantiated. The Prototype
code doesn''t look like it really allows for any use of this object
anyway. If I''ve missed something here then that changes everything.
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.

If my suggested code was used there would be less Prototype for web
users to download and less code for the Prototype community to
maintain.


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.



Note also that a semicolon at the end of this line looks like it would
make the observer section minimizable

Abstract.TimedObserver = function() {}



I know this group is very sensitive to technical criticism of
Prototype but I hope this is received well.


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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/9/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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? Are you fucking kidding me? We have the year 2006, not
1981 last time I checked!
> less code for the Prototype community to maintain.
This is a maintenance nightmare! 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? We should do this throughout
the whole code, I am sure this will be all appreciated by anyone
browsing the files.
> 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.
> 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.
> 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.
> 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 or in making
the code Mozilla warnings free. The former does not hinder me, as
Dojo''s compressor can handle this, and as for the later, this is why I
have my own patched of Prototype and Scriptaculous..

--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/9/06, Martin Bialasinski
<klingeling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 12/9/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 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 have to retract this statement. lastValue and value are both either
strings or booleans, so a type-safe comparison is not needed. But it
would not hurt either, of cause.

--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/9/06, Martin Bialasinski
<klingeling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 12/9/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter Michaux wrote:
> But we are still distributing the code every time it needs to be used
> so short without being ridiculous is better.
[snip]
> The author written inline documentation will make it abundantly clear
> what these short-lived identifiers mean.
So replace normal descriptive variable names with shorter ones to save on bytes
downloaded, but then eliminate those savings by writing documentation to explain
what those short variable names represent?

... ummm... ??? (scratching my head) ... ?? (thinking some more) ... (nope,
still confused)

-- 
Michael Peters
Developer
Plus Three, LP


--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/9/06, Michael Peters
<mpeters-aUYv5hkjw45l57MIdRCFDg@public.gmane.org>
wrote:
>
> Peter Michaux wrote:
>
> > But we are still distributing the code every time it needs to be used
> > so short without being ridiculous is better.
>
> [snip]
>
> > The author written inline documentation will make it abundantly clear
> > what these short-lived identifiers mean.
>
> So replace normal descriptive variable names with shorter ones to save on
bytes
> downloaded, but then eliminate those savings by writing documentation to
explain
> what those short variable names represent?
>
> ... ummm... ??? (scratching my head) ... ?? (thinking some more) ... (nope,
> still confused)
Code should be commented. Descriptive identifiers will never get around that.

However there is no need to ever serve comments or unnecessary
whitespace. That is just wasting time and money.

http://www.crockford.com/javascript/jsmin.html

Peter

--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Instead of renaming variables in the main source, just run an
obfuscater or do some fancy regex work over it and rename things to
whatever suits your fancy.

I''d rather be able to "understand" the code I''m
reading, rather than
"decode" it.

On 12/9/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 12/9/06, Martin Bialasinski
<klingeling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > On 12/9/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
>
--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/9/06, Andrew Kaspick
<akaspick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Instead of renaming variables in the main source, just run an
> obfuscater or do some fancy regex work over it and rename things to
> whatever suits your fancy.
obfuscaters can cause bugs

http://yuiblog.com/blog/2006/03/06/minification-v-obfuscation/

> I''d rather be able to "understand" the code I''m
reading, rather than
> "decode" it.
$$() has meaning? This is part of the Prototype API. I think it is
quite easy to keep track of a local variable called "el" for
"element"
in only 12 lines of code 3 of which are just close braces.

Even if the variable names I used are expanded it would still be
shorter than having the overhead of the abstract timer in Prototype.

Peter

--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/9/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> But we are still distributing the code every time it needs to be used
If you don''t use sane clientside caching.
> So Prototype made the decision to have a cryptic API
It is not.
> and long-named,
> short-lived local variables. Seems like the wrong way around to me.
Eat your own dog food. Convert all variables to two letter ones in
yout fork project first.

--~--~---------~--~----~------------~-------~--~----~
 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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---