Using "new function() {...}" as a Singleton

[Dmitry A. Soshnikov]

(...) But there is at least one that seemed
very odd when it first appeared, and which has become an indispensable
idiom - Cornford's Construct, `(function() {/*...*/}) ();`.

Maybe, at the very best, the [name both of them] construct, because
there's no doubt that it's been Douglas Crockford who has contributed
more than anybody else to its divulgation. Not Cornford nor c.l.js
neither its FAQ.

Again, I don't understand, why the construct which existed long time
before JavaScript should be named by Crockford's or Cornford's names?
They both not relate to function expressions and their particular view
-- with a grouping operator. Yes, maybe /you/ learned it from
Crockford's video, but before it this construction (and that is much
more essential -- ideology -- of a function literal, which can be
created dynamically, passed as a funarg, or e.g. executed right after
its creation) happily existed.

So, the name is (my proposal): "An immediately invoked function"
(without specifying even that this is an expression, because it goes
without saying).

I've witnessed for the last 3+ years the influence of this group and
it's ~= nil, what a waste, what a lost opportunity, not to mention the
fact that the few (JS newbies or not) that every now and then happen
to dare to post here asking for help or advice more often than not are
immediately repelled by the harsh + impertinent answers of no help nor
valuable advice by the usual bunch of bigoted regulars.

Yes, unfortunately that's true. But everything can be changed. You can
also start to do it. The first step (as I see) -- do not start
irrelevant discussions which turn then to useless flame and holy wars. A
classical example: some newbie asks question about inheritance and shows
a code (about 10-20 lines). In one line some finds /alert(...)/ -- and
that's it -- nobody already remember from what the discussion was
started -- everyone now discussed on 10 pages that should be (haha)
/window.alert/

OTOH, I and tens of thousands like me have learned of and about that
construct -and much more- in Crockford's videos.

It doesn't matter who has enlighten you. This ideological constructions
have been /invented/ by other people and long time before you saw
Crockford's videos or Cornford's explanations in some newsgroup. You
don't think this newsgroup is something with sacred mission right?

It's a pity, it's waste, but it's the truth, and it's been a lost
opportunity: c.l.js could have been the best resource for the JS
community but instead everybody laughs at it because of this bunch of
regulars that behave as rude little men.

Yes, start to change it. And do it.

Dmitry.

 

[Dmitry A. Soshnikov]

ah ah, the classic "lambda", I could not resist

function L(body){
var i = body.indexOf(":");
return ~i ?
Function(body.slice(0, i), "return " + body.slice(++i)) :
Function("return " + body)
;
}

L("x:2*x")(10);

That's interesting

But the same construction there is in ECMAScript:

ECMAScript:

(function (x) {
return x * 2;
})(10); // 20

Erlang:

(fun (X) ->
X * 2
)(10). % 20

And with private scope (the "invention" of which (why the heck?) is
being "awarded" to irrelevant Crockford/Cornford):

Erlang:

F = (fun (X) ->
% private
Y = 20,

% return this local FE
fun (Z) ->
X + Y + Z
end

end)(10),

F(30). % results 60

You see that Y -- is private (and closured). I guess you can build
analogue in ECMAScript.

And that's about Erlang which was invented in 1987. I'm keeping silence
about Lisp (which was invented much earlier) where parenthesis are
native for the language as a whole.

Dmitry.

 

[David Mark]

(...) But there is at least one that seemed
very odd when it first appeared, and which has become an indispensable
idiom - Cornford's Construct, `(function() {/*...*/}) ();`.

Maybe, at the very best, the [name both of them] construct, because
there's no doubt that it's been Douglas Crockford who has contributed
more than anybody else to its divulgation. Not Cornford nor c.l.js
neither its FAQ.

Divulgation?

I've witnessed for the last 3+ years the influence of this group and
it's ~= nil,

You are clearly out of your mind.

http://www.cinsoft.net/host.html

That's a nonsensical over-generalization that you are in no position to
make. And it sounds suspiciously like parroting to me (as I've
certainly heard this before). How do you account for the fact that so
many ideas that were first published here lead to blog posts, which then
influence the masses? Then the code pops up in the "major" libraries
years later. It's a slow dissemination process for sure, but impossible
to dismiss (except for the irretrievably dense or disingenuous).

Crockford doesn't know the first thing about cross-browser scripting.
His primary message there is that you should deliberately break IE6.
Good luck with that. He's a proponent of YUI and Dojo as well. Is that
the sort of thing you want to learn?

Never mind the FAQ. It's largely irrelevant.

Statements prefaced by "it's the truth" are typically whoppers of such
magnitude as to insult the reader's intelligence.

Who is everybody? Perhaps you are hanging out with the wrong crowd.

And you are hardly one to talk about being "rude" or "little". And God
knows you are laughable as well.

 

[David Mark]

(...) But there is at least one that seemed
very odd when it first appeared, and which has become an indispensable
idiom - Cornford's Construct, `(function() {/*...*/}) ();`.

Maybe, at the very best, the [name both of them] construct, because
there's no doubt that it's been Douglas Crockford who has contributed
more than anybody else to its divulgation. Not Cornford nor c.l.js
neither its FAQ.

Again, I don't understand, why the construct which existed long time
before JavaScript should be named by Crockford's or Cornford's names?
They both not relate to function expressions and their particular view
-- with a grouping operator. Yes, maybe /you/ learned it from
Crockford's video, but before it this construction (and that is much
more essential -- ideology -- of a function literal, which can be
created dynamically, passed as a funarg, or e.g. executed right after
its creation) happily existed.

So, the name is (my proposal): "An immediately invoked function"
(without specifying even that this is an expression, because it goes
without saying).

I've witnessed for the last 3+ years the influence of this group and
it's ~= nil, what a waste, what a lost opportunity, not to mention the
fact that the few (JS newbies or not) that every now and then happen
to dare to post here asking for help or advice more often than not are
immediately repelled by the harsh + impertinent answers of no help nor
valuable advice by the usual bunch of bigoted regulars.

Yes, unfortunately that's true.

It certainly is not.

But everything can be changed. You can
also start to do it. The first step (as I see) -- do not start
irrelevant discussions which turn then to useless flame and holy wars. A
classical example: some newbie asks question about inheritance and shows
a code (about 10-20 lines). In one line some finds /alert(...)/ -- and
that's it -- nobody already remember from what the discussion was
started -- everyone now discussed on 10 pages that should be (haha)
/window.alert/

You are dreaming.

 

[SteveYoungTbird]

That's a nonsensical over-generalization that you are in no position to
make. And it sounds suspiciously like parroting to me (as I've
certainly heard this before).

I'll bet you have!

<snip>

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov :


Of course, but not in any previous "mainstream" language I know.

How are /you/ relevant (and /your/ knowledge) with theoretical invention
made much earlier?

Yes, "mainstream" matters (in some degree), but let us don't call as
"inventors" those who just explain you that theoretical facts which
existed not even before Crockford's videos, but long time before
JavaScript itself. If you want you may name some person as your teacher
which helped you to understand some topic and enlighten you. But
objectively, they are not inventors. Although, helped to spread and show
some useful conceptions /applied to JavaScript/. No more, no less.

Regarding ECMAScript, its specification has exact definition of a
function expression. From the general theory, a function literal (i.e. a
first-class function object) completely corresponds to that definition
from the ECMA-262-3(5) specification. And nothing prevents to execute
this function object right after its creation -- if you want, I can show
the same examples in other languages -- in Python (from which ECMAScript
took much ideas), Ruby, Erlang again, other.

So, it can be named as "(anonymous) FE which is being executed after its
creation" or for shortness (I let myself to repeat) -- "an immediately
invoked function". Thus, word "immediately" relates to "right after the
creation". Crockford uses "immediate function" -- yeah, for shortness it
matches, but maybe doesn't concentrate attention of exactly
"invocation". I've heard "self-executing" function and think that it
isn't fit because "self-executing" is relates to a recursive function.

The point is that in javascript, you *need* such a construct much more
often than elsewhere.

1. Because the scope of identifiers is a function, not a block. So,
you may have to write

(function() {
for (var i = 0; i< 1000000; i++) {
/* do something */
}
})();

merely to be sure that your `i` is not going to overwrite an important
global some fool named "i" somewhere in a big mess of code.

Absolutely the same semantics there is in other languages. The same
again Python from which ES took much. It isn't the fact to say that some
person "invented" that idea for you. "Explained", "enlighten" -- repeat,
maybe, but not "invented".

2. Because what other languages call "static" variables have to be
implemented in closures.

Also the same, a "static" concept varies in some languages, and I can
show you an example again in the same Python with the same semantics.

And therefore, what was a cute exotic curiosity only used by CS majors
became a basic tool any beginning javascript programmer has to learn.

What does CS abbreviation mean?

Dmitry.

 

[David Mark]

I'll bet you have!

As has everybody who reads this group, genius.

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov :


I don't think it matters much, but I do have some notions of the
history of programming languages.

Excuse my, maybe a bit rude formed, sentence, but I meant that there are
things that exist without our knowing about them and without our
emotional feelings to them. That exactly I meant, -- not (your)
"knowledge", but your (my, our) "knowing" of something (i.e. to be
informed).

As Conford quite rightly points out, "It could be argued that Brendan
Eich must have 'invented' it, as it was an inherent possibility in
the language from the moment function expressions were introduced."

Yes, but Brendan Eich just borrowed this ideology (and I like it) to the
language; i.e. even he didn't invent it.

What I *would*
like, though, is that we find and agree on a short and catchy name.

Yes, then we can continue researches

"Computer science".

Ah, thanks (I of course know what is "Computer science" but haven't
heard often "CS" abbreviation).

Dmitry.

 

[Garrett Smith]

[...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.

[...]

You've qualified the term "reflect" with your own "in one way or another".

The concept of "reflects" is explained in HTML 5 draft. We've discussed
this before. A content attribute that "reflects" has its current value
represented by a dom property. Not all content attributes reflect.

http://www.w3.org/TR/html5/infrastructure.html#common-dom-interfaces

You mentioned that jQuery conflates properties and atttributes; however
they also conflate computed styles with conflation. Thus, in jQuery, the
selector:

*[width=600]

- may (incorrectly) select:

<img class="logo">

- depending on the browser, its version, and the rendering mode (or
document mode).

The jQuery team seems to either be unaware of this problem or in denial
of its existence, as evidenced by recent promotion of the following
tutorial:

| Some Good and Advanced jQuery Techniques - http://bit.ly/dli5EN
| 9:01 AM May 9th via TweetDeck

I can understand that there are problems that they won't fix but I
cannot see why they would advocate something that is obviously
incorrect. Either they are unaware of the problem (though that seems
impossible at this point) or they are aware of it and ignore it.

 

[David Mark]

On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :

[...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.

[...]

You've qualified the term "reflect" with your own "in one way or another".

Meaning that they are abstracted in some way (e.g. the "style" attribute
is reflected as an object).

The concept of "reflects" is explained in HTML 5 draft.

There you go again. How are the contents of that draft possibly
relevant to this discussion?

We've discussed
this before. A content attribute that "reflects" has its current value
represented by a dom property. Not all content attributes reflect.

Name a (standard) one that doesn't. And please stop with the "content
attribute" nonsense. They are attributes, period. I don't care that
some moron decided that DOM properties should be called attributes as
well (necessitating the need for the "content" qualifier). And, as
mentioned, it's just a draft anyway.

http://www.w3.org/TR/html5/infrastructure.html#common-dom-interfaces

Worthless. It's a draft. A few of the latest browsers implement parts
of it. Those parts are best avoided for now (in development as well as
when discussing reality).

You mentioned that jQuery conflates properties and atttributes;

Yeah, about a million times over the course of almost three years.
Somehow they haven't gotten the message, despite the fact that Resig was
the first one I told. He blathered something about "strawmen" and
scuttled off.

however
they also conflate computed styles with conflation.

They also conflate computed styles and attributes. Yes, I know. We
went over that when it was revealed they had changed their "attr" method
to call their completely broken height/width methods, which in turn
query computed styles.

Thus, in jQuery, the
selector:

*[width=600]

- may (incorrectly) select:

<img class="logo">

- depending on the browser, its version, and the rendering mode (or
document mode).

And its style of course. Yes, as noted, they seem to be lost.

The jQuery team seems to either be unaware of this problem or in denial
of its existence, as evidenced by recent promotion of the following
tutorial:

What else is new?

| Some Good and Advanced jQuery Techniques - http://bit.ly/dli5EN
| 9:01 AM May 9th via TweetDeck

"Nowadays jQuery is used in so many sites that we can't even count them.
There is a reason, jQuery is probably the most famous JavaScript framework."

Dear God. Famously awful. And as if fame were a good reason to choose
a "framework" (since when is a loopy 70K query engine a framework?)

The article then goes on to recommend using attribute-related queries
with jQuery. (!) What planet are these people from?

I can understand that there are problems that they won't fix but I
cannot see why they would advocate something that is obviously
incorrect. Either they are unaware of the problem (though that seems
impossible at this point) or they are aware of it and ignore it.

I've stopped wondering about their motivations. The end result is a
cottage industry built on top of horrible software (not to mention
explanations), intended to be deployed in the harshest environment there
is and often for mission-critical tasks. What sane person would buy
into such a thing at this point?

But ask on StackOverflow and everyone will tell you it's the greatest
thing ever (and any dissent is voted down into oblivion). Of course,
they'll also tell you it is a good idea to use the HTML5 doctype because
it is shorter and therefore less typing and easier to remember.

 

[Garrett Smith]

Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :
[...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.

[...]

You've qualified the term "reflect" with your own "in one way or another".

Meaning that they are abstracted in some way (e.g. the "style" attribute
is reflected as an object).

Did Jorge use that definition? Or did he communicate in a vague way and
you elaborated on it?

There you go again. How are the contents of that draft possibly
relevant to this discussion?

It helps explain what Jorge likely wanted to communicate to you.

Name a (standard) one that doesn't.

'checked' of HTML INPUT.

And please stop with the "content

attribute" nonsense. They are attributes, period. I don't care that
some moron decided that DOM properties should be called attributes as
well (necessitating the need for the "content" qualifier). And, as
mentioned, it's just a draft anyway.


Worthless. It's a draft. A few of the latest browsers implement parts
of it. Those parts are best avoided for now (in development as well as
when discussing reality).

Your opinion that that section of the draft is worthless does not
address the fact that the section describes what "reflects" means.

The HTML 5 draft may probably never be done, part parts of it are
getting close. That one in particular is in Last Call, so if you
disagree with the wording, send your comments to whatwg.

They also conflate computed styles and attributes. Yes, I know. We
went over that when it was revealed they had changed their "attr" method
to call their completely broken height/width methods, which in turn
query computed styles.

Thus, in jQuery, the
selector:

*[width=600]

- may (incorrectly) select:

<img class="logo">

- depending on the browser, its version, and the rendering mode (or
document mode).

And its style of course. Yes, as noted, they seem to be lost.

What "style"? The computed style? Or what would be the computed style if
the element, and all of it's ancestors, had display: block?

What about an element that has display: none doesn't have a width?

<img style="display: none" class="logo">

How wide is it now?

Being lost is acceptable. Bugs in pubic APIs are not and flaunting them
to the public as features is fraud.

It is not like these problems are edge cases, they're right there in the
tutorial that the jQuery PR team linked to.

What else is new?


"Nowadays jQuery is used in so many sites that we can't even count them.
There is a reason, jQuery is probably the most famous JavaScript framework."

Dear God. Famously awful. And as if fame were a good reason to choose
a "framework" (since when is a loopy 70K query engine a framework?)

The article then goes on to recommend using attribute-related queries
with jQuery. (!) What planet are these people from?

Not only that, they introduce that by saying that it is very accurate,
right under the term "Advanced Selectors".

| Advanced Selectors
|
| In jQuery we can use a lot of selectors, making them very accurate.
| Let’s see step by step some of them and try to get the point to be
| able to use them in other contexts.
|
| Selectors based on attributes
|
|
| Almost every element in HTML can have attributes, for instance:
|
| 1 <img src="" alt="" width="" height="" border="0" />
| 2 <input type="text" name="email" value="" size="80" />

And the width attribute on the input is what? Well, if you're jQuery in
IE, it is probably 0. IE adds properties to all sorts of objects. It
adds a width property to a lot of things including PRE, TABLE, TH, etc.

The design of jQuery is to match how an element is rendered based on CSS
selectors.

<img src="" alt="" width="10" height="" border="0" style="width: 90%"/>

The jQuery team continues to tell the world that jQuery is a CSS3
Compliant selectors engine.

It is not even close. I have been saying this for years. Are they really
unaware of the problem? If so, is everyone else too?

John Resig has been talking about how great jQuery is for years.
http://ejohn.org/blog/happy-2nd-birthday-jquery/

Maybe having a PR team helps, http://jquery.org/team but then again, if
the developer relations team is advocating a technique that exacerbates
bugs in jQuery, won't people notice that and lose faith? I'm afraid not.
I've been watching for three years. Two years ago, I believed jQuery
would be on its way out.

jQuery has not died, but rather grown in popularity.

The added convenience of CSS selector queries is outweighed by the
complexity it entails. Of course, to understand and appreciate that, one
would have to have worked with the DOM and attributes long enough to
understand the complexities and inherent problems with getting it to
work in IE and, once one understood the cost of addressing those, it
should be pretty clear that it isn't worth it.

Foresight would suffice, it would not be necessary to actually make one
to see all of the problems with doing that. However, lacking such
foresight, one might actually go and try it.

The lack of foresight is clear in the in early versions of the code,
particularly with the mistakes in its design strategy.

What motivation does the author have to state that jQuery is not a CSS 3
Compliant engine? That jQuery was not practical from the beginning? (I'm
basing this question on the speculation that he knows this is true,
because it would be pretty damned hard to deny the obviousness of it
(even for someone really dense)).

Peer respect of admitting a mistake could be a motivator for such
admissions. However, where reciprocal favors (in the form of links,
praise, networking, etc) are offered, then there will be individuals
who link to and praise jQuery and we can see that all over the web.

I am not and have never been one such individual. My opinion is not for
sale.

By the way, CSS2.1 states that attribute selectors take a string
(quoted) or identifier, as in img[width="600"], and not img[width=600],
but provided examples showing unquoted values as strings.

http://www.w3.org/TR/CSS2/syndata.html#strings

--> gym

 

[David Mark]

Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov : [...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.

[...]

You've qualified the term "reflect" with your own "in one way or another".

Meaning that they are abstracted in some way (e.g. the "style" attribute
is reflected as an object).

The concept of "reflects" is explained in HTML 5 draft.

There you go again. How are the contents of that draft possibly
relevant to this discussion?

We've discussed
this before. A content attribute that "reflects" has its current value
represented by a dom property. Not all content attributes reflect.

Name a (standard) one that doesn't.

Time. It was a trick question as there isn't one. If there was, this
demonstration would have been impossible:-

http://www.cinsoft.net/attributes.html

....as IE < 8 (and Compatibility View) have no proper attribute methods
(e.g. get/setAttribute). Yet, the example script emulates them by
referring exclusively to reflected property values.

And yes, it even works for properties that hold user input. For
example, the value attribute is reflected in the defaultValue property,
checked in defaultChecked, etc. I'm sure this information is in some
(real) specification somewhere; and if it isn't, the specification is
out of whack with reality.

Furthermore, these critical (and basic) details were never reflected in
the logic of any "major" library or framework. Clearly the neophytes
who wrote them bit off far more than they could chew with CSS selector
query engines as they don't yet know how to read documents.

These aren't newly discovered wrinkles. The rules were firmly in place
long before the first line of Prototype was written. Five years later,
the authors of jQuery, Prototype, Dojo, YUI, etc. are no closer to
solving these "mysteries". Why? Because you can't learn anything using
the peer-patch-and-pray approach to programming.

I've personally handed the answers to the owners of two of those four
projects. The response was the usual "show me where it fails!" In
Dojo's case, I tried to do that, but first needed them to define what
their (roughly 15-line) "attr" method was supposed to do. The design
appeared to be quite random; and, after all, you have to know the
expected outcome to demonstrate a failure. Their testily given response
was that I should look at the results in FF as those were "right". In
other words, it works how it works. Told that that was a circular
definition, they starting whining about "ad hominem" attacks and calling
for me to be banned from their developer mailing list. And not long
after they installed a moderator so they could "get back to having fun
again". I stopped posting as a result and, last I checked, they
were still lost in space (but having lots of fun I guess).

You aren't going to write Shakespeare if you can't read comic books. If
you a calculator says 1 + 1 = 3, don't use it to do your taxes. If a
yardstick measures a meter... Well, do I really need to go on?

Cue the apologists...

 

[David Mark]

On 5/22/2010 1:25 PM, David Mark wrote:
Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :

[...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.


[...]

You've qualified the term "reflect" with your own "in one way or
another".

Meaning that they are abstracted in some way (e.g. the "style" attribute
is reflected as an object).

Did Jorge use that definition? Or did he communicate in a vague way and
you elaborated on it?

There you go again. How are the contents of that draft possibly
relevant to this discussion?

It helps explain what Jorge likely wanted to communicate to you.

Name a (standard) one that doesn't.

'checked' of HTML INPUT.

Is that meant to be a joke? It is reflected in the defaultChecked DOM
property.

And please stop with the "content

Your opinion that that section of the draft is worthless does not
address the fact that the section describes what "reflects" means.

It was written long after the fact and is not even a standard for the
future yet. See my follow-up.

The HTML 5 draft may probably never be done, part parts of it are
getting close. That one in particular is in Last Call, so if you
disagree with the wording, send your comments to whatwg.

Not my job.

They also conflate computed styles and attributes. Yes, I know. We
went over that when it was revealed they had changed their "attr" method
to call their completely broken height/width methods, which in turn
query computed styles.

Thus, in jQuery, the
selector:

*[width=600]

- may (incorrectly) select:

<img class="logo">

- depending on the browser, its version, and the rendering mode (or
document mode).

And its style of course. Yes, as noted, they seem to be lost.

What "style"? The computed style? Or what would be the computed style if
the element, and all of it's ancestors, had display: block?

What about an element that has display: none doesn't have a width?

<img style="display: none" class="logo">

How wide is it now?

Are you asking me or pontificating in general? Obviously there is no
concept of width for an element with display:none. It's not part of the
layout.

Being lost is acceptable. Bugs in pubic APIs are not and flaunting them
to the public as features is fraud.

No kidding. I've been saying that for years.

It is not like these problems are edge cases, they're right there in the
tutorial that the jQuery PR team linked to.

They linked to _that_?!

Not only that, they introduce that by saying that it is very accurate,
right under the term "Advanced Selectors".

The author of that document is clearly a rube. Even the jQuery people
who commented seemed to sense that (yet none of them said anything about
the attribute-related issues).

| Advanced Selectors
|
| In jQuery we can use a lot of selectors, making them very accurate.
| Let’s see step by step some of them and try to get the point to be
| able to use them in other contexts.
|
| Selectors based on attributes
|
|
| Almost every element in HTML can have attributes, for instance:
|
| 1 <img src="" alt="" width="" height="" border="0" />
| 2 <input type="text" name="email" value="" size="80" />

And the width attribute on the input is what?
Missing.

Well, if you're jQuery in
IE, it is probably 0.

Yes, I know. I invented this argument. It goes nowhere. Matt Kruse
will come along and say it doesn't matter.

IE adds properties to all sorts of objects. It
adds a width property to a lot of things including PRE, TABLE, TH, etc.

The design of jQuery is to match how an element is rendered based on CSS
selectors.

jQuery has no design as such. It's simple a patchwork based on the
observations of lots of authors who have no concept of what they are
looking at.

<img src="" alt="" width="10" height="" border="0" style="width: 90%"/>

The jQuery team continues to tell the world that jQuery is a CSS3
Compliant selectors engine.

I've long since disproved that claim.

http://www.cinsoft.net/slickspeed.html

It is not even close. I have been saying this for years.

You?! That's _my_ line.

Are they really
unaware of the problem? If so, is everyone else too?

For the longest time, I thought everyone else *was* unaware. Glad to
have you on board.

John Resig has been talking about how great jQuery is for years.
http://ejohn.org/blog/happy-2nd-birthday-jquery/

I know. He's ignorant. What else is new?

Maybe having a PR team helps, http://jquery.org/team but then again, if
the developer relations team is advocating a technique that exacerbates
bugs in jQuery, won't people notice that and lose faith?

Hopefully. But they have nothing to compare it to. They just figure
that "nobody is perfect".

I'm afraid not.
I've been watching for three years. Two years ago, I believed jQuery
would be on its way out.

It is on its way out. All of them are on their way out.

jQuery has not died, but rather grown in popularity.

And that will ultimately be the death of it.

The added convenience of CSS selector queries is outweighed by the
complexity it entails.

Yes, it was ill-advised from the start.

Of course, to understand and appreciate that, one
would have to have worked with the DOM and attributes long enough to
understand the complexities and inherent problems with getting it to
work in IE and, once one understood the cost of addressing those, it
should be pretty clear that it isn't worth it.

I've long since hit that one out of the park. The jQuery-ites just
don't get it. They don't want it. They'd rather stay deluded and
happy.

Foresight would suffice, it would not be necessary to actually make one
to see all of the problems with doing that. However, lacking such
foresight, one might actually go and try it.

The lack of foresight is clear in the in early versions of the code,
particularly with the mistakes in its design strategy.

What motivation does the author have to state that jQuery is not a CSS 3
Compliant engine? That jQuery was not practical from the beginning? (I'm
basing this question on the speculation that he knows this is true,
because it would be pretty damned hard to deny the obviousness of it
(even for someone really dense)).

They are either completely stupid or lying. There's no way around that.

Peer respect of admitting a mistake could be a motivator for such
admissions. However, where reciprocal favors (in the form of links,
praise, networking, etc) are offered, then there will be individuals
who link to and praise jQuery and we can see that all over the web.

I see lots of ignorant BS on the Web. It's an idiot magnifier.

I am not and have never been one such individual. My opinion is not for
sale.

Mine is, but it is really, really expensive.

By the way, CSS2.1 states that attribute selectors take a string
(quoted) or identifier, as in img[width="600"], and not img[width=600],
but provided examples showing unquoted values as strings.

That's the least of their worries.

 

[Garrett Smith]

Garrett Smith wrote:
On 5/22/2010 1:25 PM, David Mark wrote:
Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :

[...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.


[...]

You've qualified the term "reflect" with your own "in one way or
another".

Meaning that they are abstracted in some way (e.g. the "style" attribute
is reflected as an object).

Did Jorge use that definition? Or did he communicate in a vague way and
you elaborated on it?

The concept of "reflects" is explained in HTML 5 draft.

There you go again. How are the contents of that draft possibly
relevant to this discussion?

It helps explain what Jorge likely wanted to communicate to you.

We've discussed
this before. A content attribute that "reflects" has its current value
represented by a dom property. Not all content attributes reflect.

Name a (standard) one that doesn't.

'checked' of HTML INPUT.

Is that meant to be a joke? It is reflected in the defaultChecked DOM
property.

How about autocomplete attribute, in Firefox? Or placeholder in older
versions of webkit that supported that attibute?

It was written long after the fact and is not even a standard for the
future yet. See my follow-up.

The point that it was written after the fact does not take any away from
the argument. In fact, it might actually strengthen it. The term is a
codification used to describe existing behavior.

Not my job.

You seem to disagree with the definition, but won't say why. It's not a
standard that is the topic at hand, mind you, but the meaning of a word
that is being used to describe something. That word is "reflects".

They also conflate computed styles and attributes. Yes, I know. We
went over that when it was revealed they had changed their "attr" method
to call their completely broken height/width methods, which in turn
query computed styles.

Thus, in jQuery, the
selector:

*[width=600]

- may (incorrectly) select:

<img class="logo">

- depending on the browser, its version, and the rendering mode (or
document mode).

And its style of course. Yes, as noted, they seem to be lost.

What "style"? The computed style? Or what would be the computed style if
the element, and all of it's ancestors, had display: block?

What about an element that has display: none doesn't have a width?

<img style="display: none" class="logo">

How wide is it now?

Are you asking me or pontificating in general? Obviously there is no
concept of width for an element with display:none. It's not part of the
layout.

Obviously.

But jQuery might be selecting that element, depending on the browser,
its version, the rendering mode, and other css rules. The article says
that jQuery finds the elements whose "width is 600px".

Regardless, the rendered styles is a separate concept from the
attributes in the source code. Totally separate and unrelated concept.

Attributes describe the element, styles describe its appearance.

Recent browsers that implement getComputedStyle will return a computed
style width, based on apparently a nonstandard algorithm. This is
probably as a consequence of developers wanting that value and filing
invalid bugs.

So, if that element is matched in the author's selector query
"img[width=600]" the query would not be doing what he says it does.
Namely, it would not match "all the images whose width is 600px".

That expectation is based on observations of design bug of jQuery and
even at that, the query will fail, matching an element whose display is
"none" in those recent browsers that implement getComputedStyle. In IE8
and below, it will not match the element, and so it will do what the
author says it does.

Then again, that same article throws some javascript errors in Firefox:

"getParameter is not defined"

getParameter is not defined
[Break on this error] loadSkin=function(b,a){var
c=document....lse{jQuery(function(a){loadMagic()})};

getParameter is not defined
http://www.tuttoaster.com/wp-conten...s?d=www.tuttoaster.com&r=5&s=default&onw=true
Line 1

That error was seen in Firefox 3.6 with no modifications, other than the
one extension "Firebug."

They linked to _that_?!

The tweeted about it, as explained. Read it for yourself.

http://twitter.com/jquery

[...]

I've long since disproved that claim.

Over and over again.

http://www.cinsoft.net/slickspeed.html


You?! That's _my_ line.

It is. Though it is an easily observable phenomenon. Anyone who
understands the concepts of attributes and the fundamental problems with
them IE would know right away that attempting to make even a CSS2
compliant selector engine is going to be more trouble than it is worth.

[...]

Hopefully. But they have nothing to compare it to. They just figure
that "nobody is perfect".


It is on its way out. All of them are on their way out.

Yours too?

And that will ultimately be the death of it.

You'd think. The problem is that the professional bar for "web
developer" was never very high to begin with. It used to be that one
could get away with making things work in a few browsers with a little
knowledge of the DOM and CSS.

jQuery lowered that bar. Now, you don't need to know "pure javascript"
or "raw javascript" or "low-level code" -- all of these terms used to
describe the efforts of what should be a requisite basis of
understanding of the pertinent technologies prior to seeking employment
as a professional who uses them.

Look here, jQuery is advertising that it is for designers, in just one
of the many books for jQuery is "jQuery for Designers", as featured on
the homepage.

http://jquery.com/

What would be the motivation for writing that book is what? To spread
understanding of the fundamental technologies so that people can develop
sites?

The developer knows that if he writes a book, it's gonna make him look
like a pro, while having the dual effect of providing an attractive
title, showing developers that they don't really need to know how to
program, jQuery isn't real programming and even a designer can do it.
It's like the dummies books.

He'll be helping out jQuery, by giving credence to the library. In
return, he will likely to be featured on the jQuery website, which can
help get him into a position of being recognized as something of an
expert on jQuery.

Recall earlier where I wrote:

| Where reciprocal favors (in the form of links, praise, networking,
| etc) are offered, then there will be individuals who link to and
| praise jQuery and we can see that all over the web.

Yes, it was ill-advised from the start.

The proliferation of new selector-based libraries, and of existing
libraries that have migrated to being selectors-based seems to validate
the idea. It's a neat idea, conceptually, but not practical. It fails in
the obvious places that anyone with a few years of experience developing
for IE should know of.

They're basically all copying jQuery. The idea actually started with
Dean Edwards' CSSQuery, which predated jQuery by a couple of years. Not
that that much matters.

You too validated the concept by publishing a library yourself, copying
the idea, and proclaiming it to be superior and with no unit tests, too
boot!

[...]

By the way, CSS2.1 states that attribute selectors take a string
(quoted) or identifier, as in img[width="600"], and not img[width=600],
but provided examples showing unquoted values as strings.

That's the least of their worries.

Yep. It's a separate issue and probably going to be more of an issue for
the WG to contend with, as people are used to attribute selectors
working without quotes.

It looks like the CSS2.1 spec had a mistake by providing examples that
don't match the rules stated. For attribute selectors[1], it states:

| Attribute selectors may match in four ways:
| [att]
| Match when the element sets the "att" attribute, whatever the
| value of the attribute.
| [att=val]
| Match when the element's "att" attribute value is exactly "val".
| [...]
|
| Attribute values must be identifiers or strings. The case-sensitivity
| of attribute names and values in selectors depends on the document
| language.

CSS2.1 defines strings[2] as:
| 4.3.7 Strings
|
| Strings can either be written with double quotes or with single
| quotes.

Awful wording. They use of "can" and "written with", in particular. By
that definition, I could, with my pencil, produce a string with with the
following characters, in order:

8""

Better:
| A String is zero or more characters enclosed by either single or
| double quotes.

[1] http://www.w3.org/TR/CSS2/selector.html#matching-attrs
[2]http://www.w3.org/TR/CSS2/syndata.html#strings

 

[Garrett Smith]

So what?

Is that a performance trick? For all you know, evaluating an
ArgumentList might be a greater performance hit in any one browser.

With no parameters, there would be no reason to have an argument list,
so that evaluation step would be avoided.

Regardless, the amount of CPU wasted on evaluating simple assignment to
local variables is generally very very fast and is only measurable in
the most extreme cases. Providing the initial undefined to variables is
also very simple for the interpreter and is of course very very fast.

Even if you don't scroll, you have to look twice; basically reparsing.
If the variables are assigned at the top of the function; it can be read
from top to bottom.

That's your choice, you're free in it, nobody says that it's worse. I
just said that it will be inconvenient for me to scroll down first, and
then scroll up back. That's it. There is no need to show some
alternative examples with separating definition and execution of a
function, I understand the goal and see pros and cons.

Agreed. Having the variables assigned at the bottom comes at a cost of
readability. It saves the use of the keyword `var` but that is hardly
much of a benefit and the performance boost of using parameters seems
like . The cost is readability; you have to scroll down to see the local
variables.

 

[Ry Nohryb]

(...)
Did Jorge use that definition? Or did he communicate in a vague way and
you elaborated on it? (...)

OMG, you can't even read ?

 

[David Mark]

On 5/24/2010 2:11 PM, David Mark wrote:
Garrett Smith wrote:
On 5/22/2010 1:25 PM, David Mark wrote:
Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :

[...]
You really don't know what you are talking about, do you? Bugs
notwithstanding, all standard attributes of "html-elements" are
reflected in "JS-land" in one way or another.


[...]

You've qualified the term "reflect" with your own "in one way or
another".

Meaning that they are abstracted in some way (e.g. the "style"
attribute
is reflected as an object).

Did Jorge use that definition? Or did he communicate in a vague way and
you elaborated on it?



The concept of "reflects" is explained in HTML 5 draft.

There you go again. How are the contents of that draft possibly
relevant to this discussion?


It helps explain what Jorge likely wanted to communicate to you.

We've discussed
this before. A content attribute that "reflects" has its current value
represented by a dom property. Not all content attributes reflect.

Name a (standard) one that doesn't.

'checked' of HTML INPUT.

Is that meant to be a joke? It is reflected in the defaultChecked DOM
property.

How about autocomplete attribute, in Firefox? Or placeholder in older
versions of webkit that supported that attibute?

Is it your assertion those are standard attributes? That was the
question, after all.

The point that it was written after the fact does not take any away from
the argument. In fact, it might actually strengthen it. The term is a
codification used to describe existing behavior.

Nothing could possibly strengthen your argument at this point.

You seem to disagree with the definition, but won't say why.

I said nothing of the sort. I said all standard attributes reflect.
You said that some of them did not and defined "reflect" as meaning that
an attribute "has its current value represented by a dom property". I
said name one. You failed to name a standard property that fits that
bill. I pointed this out and you named some non-standard properties.
Life is too short for this nonsense.

It's not a
standard that is the topic at hand, mind you, but the meaning of a word
that is being used to describe something. That word is "reflects".

See above.

They also conflate computed styles and attributes. Yes, I know. We
went over that when it was revealed they had changed their "attr"
method
to call their completely broken height/width methods, which in turn
query computed styles.

Thus, in jQuery, the
selector:

*[width=600]

- may (incorrectly) select:

<img class="logo">

- depending on the browser, its version, and the rendering mode (or
document mode).

And its style of course. Yes, as noted, they seem to be lost.

What "style"? The computed style? Or what would be the computed style if
the element, and all of it's ancestors, had display: block?

What about an element that has display: none doesn't have a width?

<img style="display: none" class="logo">

How wide is it now?

Are you asking me or pontificating in general? Obviously there is no
concept of width for an element with display:none. It's not part of the
layout.

Obviously.

But jQuery might be selecting that element, depending on the browser,
its version, the rendering mode, and other css rules. The article says
that jQuery finds the elements whose "width is 600px".

They have no idea what they are doing. That's not news. But I checked
their latest and they don't even call their own "attr" function in the
query portion, so the height/width thing I was referring to does not
apply. Apparently you meant that their docs were wrong. That's not
news either.

Regardless, the rendered styles is a separate concept from the
attributes in the source code. Totally separate and unrelated concept.

Yes, it is.

Attributes describe the element, styles describe its appearance.

Recent browsers that implement getComputedStyle will return a computed
style width, based on apparently a nonstandard algorithm. This is
probably as a consequence of developers wanting that value and filing
invalid bugs.

That's why you should use my patented avoidance technique.

http://www.cinsoft.net/size.html

Positions too:

http://www.cinsoft.net/position.html

So, if that element is matched in the author's selector query
"img[width=600]" the query would not be doing what he says it does.
Namely, it would not match "all the images whose width is 600px".

Yes, it's all nonsense. Don't rely on these silly query engines (or
their documentation).

http://www.cinsoft.net/slickspeed.html

That expectation is based on observations of design bug of jQuery and
even at that, the query will fail, matching an element whose display is
"none" in those recent browsers that implement getComputedStyle. In IE8
and below, it will not match the element, and so it will do what the
author says it does.

I think you are a bit confused about how jQuery's Sizzle thing works.

Then again, that same article throws some javascript errors in Firefox:

"getParameter is not defined"

getParameter is not defined
[Break on this error] loadSkin=function(b,a){var
c=document....lse{jQuery(function(a){loadMagic()})};

getParameter is not defined
http://www.tuttoaster.com/wp-conten...s?d=www.tuttoaster.com&r=5&s=default&onw=true

Line 1

That error was seen in Firefox 3.6 with no modifications, other than the
one extension "Firebug."

They have no idea what they are doing (like most Web developers). I see
such errors pop up in Opera 10.5, IE8, etc. And those are the browsers
that their chosen code monkeys profess to "care" about.

The tweeted about it, as explained. Read it for yourself.

http://twitter.com/jquery

I'll pass. Twitter is full of gushing twits. ISTM they all love jQuery
like a son.

[...]

I've long since disproved that claim.

Over and over again.

http://www.cinsoft.net/slickspeed.html


You?! That's _my_ line.

It is. Though it is an easily observable phenomenon. Anyone who
understands the concepts of attributes and the fundamental problems with
them IE would know right away that attempting to make even a CSS2
compliant selector engine is going to be more trouble than it is worth.

Yes, it's a complete waste of time.

[...]

Hopefully. But they have nothing to compare it to. They just figure
that "nobody is perfect".


It is on its way out. All of them are on their way out.

Yours too?

Sure. Granted, I started marketing it much too late for it to be "in".

You'd think. The problem is that the professional bar for "web
developer" was never very high to begin with.
Right.

It used to be that one
could get away with making things work in a few browsers with a little
knowledge of the DOM and CSS.

ISTM you still can in the sense that ignorant site owners will still
hire you. There seems to be no way to derail a Web development career.

jQuery lowered that bar. Now, you don't need to know "pure javascript"
or "raw javascript" or "low-level code" -- all of these terms used to
describe the efforts of what should be a requisite basis of
understanding of the pertinent technologies prior to seeking employment
as a professional who uses them.
Yes.


Look here, jQuery is advertising that it is for designers, in just one
of the many books for jQuery is "jQuery for Designers", as featured on
the homepage.

http://jquery.com/

What would be the motivation for writing that book is what? To spread
understanding of the fundamental technologies so that people can develop
sites?

The developer knows that if he writes a book, it's gonna make him look
like a pro, while having the dual effect of providing an attractive
title, showing developers that they don't really need to know how to
program, jQuery isn't real programming and even a designer can do it.
It's like the dummies books.
Yes.


He'll be helping out jQuery, by giving credence to the library. In
return, he will likely to be featured on the jQuery website, which can
help get him into a position of being recognized as something of an
expert on jQuery.
Yes.


Recall earlier where I wrote:

| Where reciprocal favors (in the form of links, praise, networking,
| etc) are offered, then there will be individuals who link to and
| praise jQuery and we can see that all over the web.


The proliferation of new selector-based libraries, and of existing
libraries that have migrated to being selectors-based seems to validate
the idea. It's a neat idea, conceptually, but not practical. It fails in
the obvious places that anyone with a few years of experience developing
for IE should know of.

Last I checked, Prototype was "standardizing" on "Sizzle". There's a
match made in hell. Dojo gives you the choice of their "ACME" (favorite
vendor of Wile E. Coyote) engine or "Sizzle". Pick your poison.

They're basically all copying jQuery. The idea actually started with
Dean Edwards' CSSQuery, which predated jQuery by a couple of years. Not
that that much matters.

I've always said the "MacGyver" should be considered harmful. Virtually
all of his scripts are ill-advised hacks and/or riddled with UA-based
browser sniffing.

You too validated the concept by publishing a library yourself, copying
the idea, and proclaiming it to be superior and with no unit tests, too
boot!

Are you being silly? I've always said the (completely optional) query
portion was basically a parody and should not be used. And the
comparisons between mine and the products of the "many eyes" projects
are quite illuminating. As was well documented last winter, it didn't
take more than a few weekends to accomplish what they have failed to do
in five years. You better believe it is superior (in virtually every
way possible). So if you must, you best use mine.

And I do have unit tests, not to mention the most extensive query tests
in the business (which are essentially unit tests themselves).

[...]

By the way, CSS2.1 states that attribute selectors take a string
(quoted) or identifier, as in img[width="600"], and not img[width=600],
but provided examples showing unquoted values as strings.

That's the least of their worries.

Yep. It's a separate issue and probably going to be more of an issue for
the WG to contend with, as people are used to attribute selectors
working without quotes.

Now that QSA is here, using a two-level QSA with a side of mish-mash
library is beyond ludicrous. Of course QSA behaves very differently
than the handmade query engines, which are demonstrably incomplete and
full of bugs. What the hell are people thinking using something like
"Sizzle" as a fallback? What the hell were the authors of these things
thinking providing such "solutions"; oh wait, they were thinking they
better bottle something quick as their only idea had been taken over by
the browsers.

http://ejohn.org/blog/thoughts-on-queryselectorall/#postcomment

Idiots.

 

[Eric Bednarz]

That type of pattern allows an object to have private scope.

I understand that, but I still don’t understand what a singleton is in a
class-free language, and why anybody would want one.

 

[Garrett Smith]

Garrett Smith wrote:
On 5/24/2010 2:11 PM, David Mark wrote:
Garrett Smith wrote:
On 5/22/2010 1:25 PM, David Mark wrote:
Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :

[...]

[...]

But jQuery might be selecting that element, depending on the browser,
its version, the rendering mode, and other css rules. The article says
that jQuery finds the elements whose "width is 600px".

They have no idea what they are doing. That's not news. But I checked
their latest and they don't even call their own "attr" function in the
query portion, so the height/width thing I was referring to does not
apply. Apparently you meant that their docs were wrong. That's not
news either.

Apparently I was referring to an article that the jQuery team tweeted
about. I've stated that several times now. Get with the picture.

That's why you should use my patented avoidance technique.

http://www.cinsoft.net/size.html

That one's obviously no good. If you'd tested it you would probably have
realized that.

Positions too:

http://www.cinsoft.net/position.html

Where are the unit tests?

So, if that element is matched in the author's selector query
"img[width=600]" the query would not be doing what he says it does.
Namely, it would not match "all the images whose width is 600px".

Yes, it's all nonsense. Don't rely on these silly query engines (or
their documentation).

http://www.cinsoft.net/slickspeed.html

Pass on that.

I think you are a bit confused about how jQuery's Sizzle thing works.

[...]

Are you bluffing?

What jQuery does for attribute selectors is inconsistent with the CSS
2.1-based Selectors API (draft). jQuery results are inconsistent and
depend on the element, its applied style values, the browser, its
version, the rendering mode, whether or not attributes are quoted,
whether or not the "context" param is present.

jQuery wraps QSA in try catch that will often, depending on the code,
result in the catch block being entered. At that point the hand-rolled
query engine is used. Throwing errors is a performance hit, and one
which I would certainly want to avoid, however considering the other
inefficiencies in jQuery, I could see how this could seem insignificant
to the author(s).

The author of that article stated that the attribute selectors provide a
"very accurate" way to "select the elements knowing their attributes and
values".

The examples he provided have a comment that contradicts what he says it
does in the article; that: "img[width=600]" matches "all the images
whose width is 600px".

That selector will do that in certain cases and in certain browsers, but
not consistently across the browsers that are supported. What the
comment says sure doesn't match anything close to native Selector API
(and the query itself is invalid anyway).

Sizzle matches nodes based on the DOM that the browser builds. The DOM
varies, especially in various versions IE. Trying to accommodate for
those shortcomings is, as I stated earlier, not outweighed by the
complexity entailed by that.

Results depending on the selector text used, quotes on attribute values,
the presence of a `context` arg (second param for jQuery(selector,
context)), can have a result that seems paradoxical, like a
"Shroedinger's Cat" result.

[...]

Are you being silly? I've always said the (completely optional) query
portion was basically a parody and should not be used. And the
comparisons between mine and the products of the "many eyes" projects
are quite illuminating. As was well documented last winter, it didn't
take more than a few weekends to accomplish what they have failed to do
in five years. You better believe it is superior (in virtually every
way possible). So if you must, you best use mine.

YOu wanna know what's silly? Designing an API "to make a mockery of
jQuery". Worse yet, providing an interface with methods "E" and "Q" and
whatever the other one-letter method names are, along with other badly
named abstractions that provide value, such as gEBI or getEBI, etc. Just
use the real method: document.getElementById.

All this, while claiming to be superior. Where are those unit tests you
keep mentioning, BTW?

And I do have unit tests, not to mention the most extensive query tests
in the business (which are essentially unit tests themselves).

....

[...]



By the way, CSS2.1 states that attribute selectors take a string
(quoted) or identifier, as in img[width="600"], and not img[width=600],
but provided examples showing unquoted values as strings.

That's the least of their worries.

I think you are a bit confused about how jQuery's Sizzle thing works.

Now that QSA is here, using a two-level QSA with a side of mish-mash
library is beyond ludicrous. Of course QSA behaves very differently
than the handmade query engines, which are demonstrably incomplete and

You don't say? So was there something to attribute selectors being
unquoted after all?

full of bugs. What the hell are people thinking using something like
"Sizzle" as a fallback? What the hell were the authors of these things
thinking providing such "solutions"; oh wait, they were thinking they
better bottle something quick as their only idea had been taken over by
the browsers.

Using QSA might make sense in the near future, depending on how widely
it is implemented. It is incompatible with the libraries today.

As to what "they" are thinking, you can either guess or assume. You
could, for example ask:

| What is the rationale for using Sizzle as a fallback when QSA is
| unsupported? Are you aware that the two are incompatible?

You could start a new thread on that and even post a link from jQuery
forums (or tweet or blog, etc). Keep in mind that if you call names and
insults, it becomes a lot easier to dismiss your criticism as biased hate.

Garrett

 

[Garrett Smith]

On 5/24/2010 6:57 PM, David Mark wrote:
Garrett Smith wrote:
On 5/24/2010 2:11 PM, David Mark wrote:
Garrett Smith wrote:
On 5/22/2010 1:25 PM, David Mark wrote:
Ry Nohryb wrote:
On 22/05/10 16:22, Johannes Baagoe wrote:

Dmitry A. Soshnikov :

[...]

[...]

http://www.cinsoft.net/size.html

That one's obviously no good. If you'd tested it you would probably have
realized that.

I meant the following (position) is no good. The previous one (size)
looks OK.

Where are the unit tests?

Garrett