On May 20, 10:02 pm, RobG <[EMAIL PROTECTED]> wrote:
> On May 21, 10:45 am, kangax <[EMAIL PROTECTED]> wrote:
>
> > Sometimes I hate how in order to make things efficient (?), the code
> > size becomes really huge:
>
> > var getText = (function(){
> > var type = document.createElement('div');
>
> I think a more appropriate name for that variables is "temp" or maybe
> just t or x or whatever.
>
Not sure how "type" slipped in there, but it was originally an
"element" of course : ) (need to be more careful next time)
> > if (typeof element.textContent != 'undefined') {
>
> I think you meant:
>
> if (typeof type.textContent != 'undefined') {
>
> I don't see the point of a comparison with 'undefined' given that we
> know we want a string and only a string (maybe some implementation
> decides to return 'object' or 'function' or 'null' or such
> weirdness). The above is no better than:
>
> if (type.textContent) {
>
I didn't want to enforce certain result type (i.e. string) therefore
test for not "undefined". Testing for "string" definitely makes sense
in this case if that's what function guarantees to return.
> Some would argue that the strict equals operator (=== ) should be
> used. So:
>
I don't use strict comparison with "typeof" since both values are of
the same type, but I guess it's a matter of preference/conventions.
> var t = document.createElement('div');
> if (typeof t.textContent === 'string') {
>
> > return function(element) {
> > return element.textContent;
> > }
> > }
> > else if (typeof element.innerText != 'undefined') {
> > return function(element) {
> > return element.innerText;
> > }
> > }
> > return function(){};
> > })();
>
> Considering the result is more complex code, the benefit of such
> optimisation must be weighed against the loss of simplicity.
>
> I expect that before the above becomes noticeably faster the function
> will have to be run several thousand times in succession. That is
> unlikely to occur so very little (if anything) will be gained by such
> optimisation. I'd rather stick with simplicity.
>
As I mentioned, I wasn't sure if code complexity is worth the
performance gains of this "optimization". I always find such decisions
a pain to make.
Best,
kangax
--~--~---------~--~----~------------~-------~--~----~
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@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
