From: Scott Sauyet on
On Mar 6, 4:45 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Scott Sauyet wrote:
> > David Mark wrote:
> >> Scott Sauyet wrote:
> >>> Things like this are very convenient:
> >>> select("div.navigation a:not(li.special a)");
> >> Honestly, that looks ludicrous to me.
>
> > Okay, it might look that way to you.  To me it is a very concise and
> > intuitive way to say "select all the anchor elements that are inside
> > divs with a class of navigation but are not inside list items with a
> > class of special, and by the way, return them in document order,
> > please."  That was the requirement.
>
> The question remains, though, did the requirement make sense in the first
> place?  Was it really not possible to solve this problem differently, for
> example with event bubbling, with using the CSS cascade, with using
> standards-compliant event-handler attributes, or a combination of them?  
> And then, is the approach that had been chosen to meet the requirement more
> or at least equally reliable than the alternatives? [ ... ]

These, of course, are useful and important questions.

I'm bothered, though, that a number of people here seem to feel they
know the answers to them in the abstract without any knowledge of
specifics of various situations. There seems to be a consensus among
some of the regulars in c.l.j.s. that CSS selector engines are a bad
idea; I'm not sure of the basis for that consensus. but it seems to be
strong enough that people are willing to assume those who disagree
have misunderstood either their own requirements or have failed to
consider alternatives. There seems to be no room for the possibility
that people have the requirements right, understand the alternatives,
and choose to use selector engines.

I'm reminded of when I came aboard a Java project just after a
consultant had left. He was supposed to be an expert in Object-
oriented development and design. He had radically reworked various
sections of code, trying to fix code smells he saw. But he did so
blindly, following some rote rules that might be fine in the abstract,
but didn't always apply. One of his "code smells" was that OO systems
should never need "switch" statements. He methodically went through
the code base, adding little helper classes (this was before "enum" in
Java) to replace the switch statements. In the end, he managed to
replace a handful of poorly conceived switch statements with better
designs. But he also replaced ten times as many switch statements
with code that was longer, less readable, less performant, and far
less maintainable than it started out. The trouble was that the
system had been well-designed, and the choice to use a switch
statement was made by people who usually did understand the trade-offs
made.

Sure, there have been times when I've used selector engines when there
were other reasonable alternatives. But there are plenty of times
when event delegation or other alternatives were not practical or even
possible, times when -- with or without a selector engine -- I needed
to operate on a collection of elements in the document.

I'm wondering if people here regularly work in fairly ideal
environments where they're in charge of all the mark-up and all the
CSS as well as all the JS used. While I'm sometimes in that
situation, it's much more common for me to be trying to squeeze some
behavior into existing HTML/CSS, often interspersed with existing JS.
It's often dictated by the project whether I can use inline JS. Often
a JS library has been chosen, and I must use it. Often parts of my
page are generated by black box systems.

Is this sort of environment unusual here?

-- Scott
From: Jorge on
On Mar 7, 6:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote:
> (...) I imagine the analysis
> is much harder to do when global variables or global objects
> are involved.(...)

I wonder why you and Lasse keep saying this. ISTM that once the JS's
single thread of execution enters that while () {} nothing is going to
interrupt it, so it's safe to assume that nothing but the code inside
the "while" is going to touch them (the globals), isn't it so ?
--
Jorge.
From: Lasse Reichstein Nielsen on
Jorge <jorge(a)jorgechamorro.com> writes:

> On Mar 7, 6:31�pm, Antony Scriven <adscri...(a)gmail.com> wrote:
>> (...) I imagine the analysis
>> is much harder to do when global variables or global objects
>> are involved.(...)
>
> I wonder why you and Lasse keep saying this. ISTM that once the JS's
> single thread of execution enters that while () {} nothing is going to
> interrupt it, so it's safe to assume that nothing but the code inside
> the "while" is going to touch them (the globals), isn't it so ?

Most of the time, yes. For certain: No.

With global variables, any function call must be assumed to be able to
change the value of any global variable - unless you do cross-function
analysis. In Javascript, cross-function analysis is *hard* because
functions are first class values, so function variables can vary.

With ES5 getters and setters, any property access, including reading
and writing global variables, can call a function that can change
any global variable.
On top of that, any object that sneaks into the loop might be coerced
to a value by calling valueOf or toString on it - which can again change
anything in the world.
And any function called inside the loop, e.g., Math.floor, might
have been overwritten by a malicious user. You really can't trust
anything in Javascript except operators working on primitive values.

This gives many, many cases where a simple one-function analysis must
surrender, because it simply cannot guarantee anything about the usage
of a global variable.

On top of this, accessing global variables in browsers are likely to
incur extra overhead from XSS security checks.

In short: Don't use global variables in speed sensitive code.

It's still not as bad as using eval or with, which means that
you can pretty much not determine anything about the scope
statically. And about the usage of any variable in scope of the
eval.
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: Antony Scriven on
On Mar 8, 6:17 pm, Jorge wrote:

> On Mar 7, 6:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote:
>
> > (...) I imagine the analysis [optimizing empty loops
> > into a no-op] is much harder to do when global
> > variables or global objects are involved.(...)
>
> I wonder why you and Lasse keep saying this. ISTM that
> once the JS's single thread of execution

Actually do you have a reference to the part in the standard
that guarantees that? I can't for the life of me find it.
I'm probably just being thick, sorry.

> enters that while () {} nothing is going to interrupt it,
> so it's safe to assume that nothing but the code inside
> the "while" is going to touch them (the globals), isn't
> it so ?

Sorry, I was talking in more general terms. Consider

for(i=0; i<5; ++i){}

where 'i' is global. If 'i' is used at some point after the
loop, then I'd expect the increments to take place. Whether
'i' is used at later is probably impossible to determine.

It may also be inadvisable to replace the loop with 'i=5;'
as an optimization. Certainly in Firefox you can do the
following.

this.watch('i', function(){
return 1000;
});
for(i=0; i<5; ++i){}

Thus changing 'i' here has a side effect. And then there's
the case where the condition uses a global as well.

for(i=0; i<imax; ++i){}

I guess you could perform a run-time check on imax here.
But if you don't know whether or not 'i' is going to be
used later on it's probably pointless. --Antony
From: Jorge on
On Mar 8, 8:35 pm, Antony Scriven <adscri...(a)gmail.com> wrote:
> On Mar 8, 6:17 pm, Jorge wrote:
>
>  > On Mar 7, 6:31 pm, Antony Scriven <adscri...(a)gmail.com> wrote:
>  >
>  > > (...) I imagine the analysis [optimizing empty loops
>  > > into a no-op] is much harder to do when global
>  > > variables or global objects are involved.(...)
>  >
>  > I wonder why you and Lasse keep saying this. ISTM that
>  > once the JS's single thread of execution
>
> Actually do you have a reference to the part in the standard
> that guarantees that? I can't for the life of me find it.
> I'm probably just being thick, sorry.

I can't find it either in the specs, but, have you ever seen one that
isn't ?

http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html
--
Jorge.