to learn jQuery if already using prototype
liketofindoutwhy
Bungee book... and wonder if I should get some books on jQuery (jQuery
in Action, and Learning jQuery) and start learning about it too?
Once I saw a website comparing Prototype to Java and jQuery to Ruby...
but now that I read more and more about Prototype, it is said that
Prototype actually came from Ruby on Rails development and the creator
of Prototype created it with making Prototype work like Ruby in mind.
Is jQuery also like Ruby? Thanks so much for your help.
Thomas 'PointedEars' Lahn
> I am learning more and more Prototype and Script.aculo.us and got the
> Bungee book... and wonder if I should get some books on jQuery (jQuery
> in Action, and Learning jQuery) and start learning about it too?
Prototype.js, and consequently everything based upon it, like
Script.aculo.us, is junk. The jQuery junk support forums are
elsewhere, too.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
kangax
wrote:
Questions regarding prototype.js are better to be asked at
http://groups.google.com/group/rubyonrails-spinoffs
Best,
kangax
beegee
wrote:
> Once I saw a website comparing Prototype to Java and jQuery to Ruby...
In a very, very superficial way, yes but no, forget what I just said.
I can't make the connection (not having read the site). Ruby and
Javascript are dynamic languages. JQuery and Prototype would not be
possible if Javascript was a compiled language like Java. And I
personally think Ruby is a beautiful language whereas I haven't
experienced a library whose "use code" looks quite as ugly as JQuery.
As PointedEars said, they are both junk. If you insist on a library,
check out YUI which is a lot like Javascript.
Thomas 'PointedEars' Lahn
> [...] liketofindoutwhy [...] wrote:
>> Once I saw a website comparing Prototype to Java and jQuery to Ruby...
>
> In a very, very superficial way, yes but no, forget what I just said.
> I can't make the connection (not having read the site). Ruby and
> Javascript are dynamic languages. JQuery and Prototype would not be
> possible if Javascript was a compiled language like Java.
For that matter, at least JavaScript[tm] *is* a compiled language like Java.
Don't confuse prompt execution with no-compilation.
> [...]
> As PointedEars said, they are both junk. If you insist on a library,
> check out YUI which is a lot like Javascript.
I think you miss the point. YUI is *supposedly* only "more like
'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
that its developers *supposedly* knew enough about the programming languages
to unleash their full potential without having to resort to inefficient and
error-prone detours of inventing "classes" and "initializers" where there
are already prototypes and constructors.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
liketofindoutwhy
wrote:
> liketofindoutwhy wrote:
> > I am learning more and more Prototype and Script.aculo.us and got the
> > Bungee book... and wonder if I should get some books on jQuery (jQuery
> > in Action, and Learning jQuery) and start learning about it too?
> > [...]
>
> Prototype.js, and consequently everything based upon it, like
> Script.aculo.us, is junk. The jQuery junk support forums are
> elsewhere, too.
So you mean Prototype and jQuery are both junk? Can you give some
points as to why you think so? For example, how else would you pass a
call back function binding to the current scope, such as
processData.bind(this) ? I kind of like the arr.each(function(x)
{ ... }) or the arr.sort().uniq().join(" ") syntax.
Thomas 'PointedEars' Lahn
> On Apr 15, 4:47 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Prototype.js, and consequently everything based upon it, like
>> Script.aculo.us, is junk. The jQuery junk support forums are
>> elsewhere, too.
>
> So you mean Prototype and jQuery are both junk? Can you give some
> points as to why you think so?
I want popcorn.
humeniuc
wrote:
> Prototype.js, and consequently everything based upon it, like
> Script.aculo.us, is junk. The jQuery junk support forums are
> elsewhere, too.
>
> PointedEars
The list of the ones who uses, and consider Prototype or jQuery is
good coded is long... very long.
Some famous users:
Apple(http://www.apple.com/) uses Prototype
Google code (http://code.google.com/) uses jQuery
NASA(http://www.nasa.gov/) uses Prototype
Mozilla Addons (http://addons.mozilla.org/) uses jQuery
CNN (betaversion http://beta.cnn.com/) uses Prototype
I think PointedEars is wrong. If he could do better than jQuery,
Prototype, or YUI, maybe he could make examples of his 'great' work.
But i think he could not.
Thomas 'PointedEars' Lahn
> On Apr 16, 2:47 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Prototype.js, and consequently everything based upon it, like
>> Script.aculo.us, is junk. The jQuery junk support forums are
>> elsewhere, too.
>
> The list of the ones who uses, and consider Prototype or jQuery is
> good coded is long... very long.
> Some famous users:
>
> Apple(http://www.apple.com/) uses Prototype
> Google code (http://code.google.com/) uses jQuery
> NASA(http://www.nasa.gov/) uses Prototype
> Mozilla Addons (http://addons.mozilla.org/) uses jQuery
> CNN (betaversion http://beta.cnn.com/) uses Prototype
So what? They all have made the wrong design decision. Whether source code
is good is not defined by those who use it but by the source code itself.
Yours is an "appeal to authority" fallacy, BTW.
> I think PointedEars is wrong. If he could do better than jQuery,
> Prototype, or YUI, maybe he could make examples of his 'great' work.
> But i think he could not.
And an ad hominem fallacy in addition.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Gregor Kofler
> The list of the ones who uses, and consider Prototype or jQuery is
> good coded is long... very long.
> Some famous users:
And I suppose equally groundbreaking when it comes to web authoring.
> Apple(http://www.apple.com/) uses Prototype
The website is HTML 4 *Transitional* - still issues several warnings.
YSlow rates it "F". Flexible layouts? Never heard of these.
> Google code (http://code.google.com/) uses jQuery
More or less the same. Can't find jQuery in the scripts list, perhaps it
is included in another one.
> NASA(http://www.nasa.gov/) uses Prototype
As another one with pointed ears would have put it: "Fascinating".
Proprietary doctype. 48 warnings. Again: Layouting from the last century.
Starts with:
<script type="text/javascript">
/**
* Browser Detect Class (sic!)
*/
function detectBrowserClass(modern){
var nBrowser = navigator.appName;
var nVersion = navigator.appVersion;
var nAgent = navigator.userAgent;
this.version;
this.browser;
this.os;
this.modern = (typeof modern == 'object') == true ? modern:0;
if(nVersion.indexOf('Windows') !=-1){
this.os = 'win';
}else{
this.os = (nVersion.indexOf('Macintosh') !=-1) == true ? 'mac':'other';
}
Those guys definitely know, what they're doing... Apart from that
they've added around 400kB of various JS libraries. Seems as if
prototype isn't capable of anything.
> CNN (betaversion http://beta.cnn.com/) uses Prototype
Super slow loading - about 50% of the 630kB payload is eaten up by JS
files...
> I think PointedEars is wrong. If he could do better than jQuery,
> Prototype, or YUI, maybe he could make examples of his 'great' work.
He frequently posts links to his "work". Anyway, I suppose since Richard
Cornford, Douglas Crockford, Randy Webb and others also question the
quality of these libraries frequently, they're clueless ignorants, too.
Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
VK
> > Apple(http://www.apple.com/) uses Prototype
>
> The website is HTML 4 *Transitional* - still issues several warnings.
So what? HTML 4 Transitional is the only usable doctype so far - until
HTML 5 will finally arrive. HTML 4 Strict is missing some vital
features like target attribute for links and iframe. Moreover HTML 4
Strict puts IE6 into W3C box model and it doesn't understand box-
sizing: border-box to switch it back to normal. So while IE6 is still
in consideration and while HTML 5 is not ready, HTML 4 Transitional is
the only one you can really work with.
> Flexible layouts? Never heard of these.
Nor me. At least not a single one that could be trusted. The choice is
very simple here: do you want flexible (liquid) layout or do you want
another contract work?
Moreover any modern browser now supports Ctrl+/- magnifier, so the
need of flexible (liquid) layouts - which was a workaround for IE4/5/6
display augmentation weakness - is mostly over.
> > Google code (http://code.google.com/) uses jQuery
>
> More or less the same. Can't find jQuery in the scripts list, perhaps it
> is included in another one.
Look at the http://code.google.com page source itself. It loads
http://code.google.com/js/codesite.pack.01312008.js
which is jQuery 1.2.3
> > NASA(http://www.nasa.gov/) uses Prototype
>
> As another one with pointed ears would have put it: "Fascinating".
> Proprietary doctype. 48 warnings. Again: Layouting from the last century.
> Starts with:
>
> <script type="text/javascript">
> /**
> * Browser Detect Class (sic!)
> */
> function detectBrowserClass(modern){
> var nBrowser = navigator.appName;
> var nVersion = navigator.appVersion;
> var nAgent = navigator.userAgent;
> this.version;
> this.browser;
> this.os;
> this.modern = (typeof modern == 'object') == true ? modern:0;
> if(nVersion.indexOf('Windows') !=-1){
> this.os = 'win';}else{
>
> this.os = (nVersion.indexOf('Macintosh') !=-1) == true ? 'mac':'other';
>
> }
>
> Those guys definitely know, what they're doing... Apart from that
> they've added around 400kB of various JS libraries. Seems as if
> prototype isn't capable of anything.
NASA is a US governmental unit, their site is under FOIA and ADA
rules. Whatever they had to be done to not be sued they had to do. If
you are a US citizen - or you know one to help you - contact NASA at
http://www.nasa.gov/help/contact/index.html showing where and how the
site accessibility or usability is broken for you.
> > CNN (betaversionhttp://beta.cnn.com/) uses Prototype
>
> Super slow loading - about 50% of the 630kB payload is eaten up by JS
> files...
It takes 3sec on my 4Mb/sec downstream DSL for the initial page
display where the download itself takes 0.39sec You may want to
consider switching from Dial-Up to something more speedy ;-)
humeniuc
have the right to an opinon. Prototype helped me in developement and
other found a help in jQuery.
"They all have made the wrong design decision."
From this afirmation, I could say you are with "appeal to authority".
If you sad that they made wrong descisions, show us some good
decision. Where did they made wrong decisions?
Invitation: post here some links of your works, so anybody could see
good code, better than Prototype or jQuery.
Could you, please?
---------------------
Gregor, I only wanted to point that many sites uses that libraryes.
Google code have an "/js/codesite.pack.01312008.js" -- minified
version of jQuery
> He frequently posts links to his "work".
I haven't seen any work of this person, I will search deeply in his
archive, but until now all that I saw was a lot of sarcasm and acid
remarks, but maibe PointedEars is a great programmer, in which case
wee should see some great code or some urls with that work from
him. :) (eventualy....)
All my best
Gregor Kofler
> Gregor, I only wanted to point that many sites uses that libraryes.
> Google code have an "/js/codesite.pack.01312008.js" -- minified
> version of jQuery
That's what I meant with "included in another one".
>> He frequently posts links to his "work".
>
> I haven't seen any work of this person, I will search deeply in his
> archive, but until now all that I saw was a lot of sarcasm and acid
> remarks, but maibe PointedEars is a great programmer, in which case
> wee should see some great code or some urls with that work from
> him. :) (eventualy....)
The discussion about the "quality" of jQuery et al pops up frequently.
Anyway, as I noted: Thomas is not the only one. You can search for
previous threads on this topic. You can search for the other names (and
their work; David Mark comes to my mind, too). You know how to use
search engines.
Anyway, the point that somebody has to show off his own work before
being allowed to critize others work, is a poor one. You don't have to
be a chef to rate something as tasty or not.
humeniuc
> being allowed to critize others work, is a poor one. You don't have to
> be a chef to rate something as tasty or not.
I agree with you. I exagerated a little here, but i was a little
iritated about Tomas atitude and his acid posts, not only in this
topic.
I reached his site, I see that he is a good programmer, but his
atitude ....
about jQuery quality, can't make a statement, I have coleagues who use
it and are happy with it.
I prefer Prototype. I don't know what programing rules broke Prototype
developers (if you have some links, discutions, please share), but
works for me.
Sorry if I offended someone, and happy programming. In pure
Javascript, Prototype, jQuery, YUI or what suits :)
Good day to all.
Gregor Kofler
> I agree with you. I exagerated a little here, but i was a little
> iritated about Tomas atitude and his acid posts, not only in this
> topic.
> I reached his site, I see that he is a good programmer, but his
> atitude ....
>
> about jQuery quality, can't make a statement, I have coleagues who use
> it and are happy with it.
> I prefer Prototype. I don't know what programing rules broke Prototype
> developers (if you have some links, discutions, please share), but
> works for me.
Perhaps this one:
<http://groups.google.at/group/comp.lang.javascript/browse_frm/thread/2072e63631688fc4/d63033d712a89e02>
RobG
> humeniuc meinte:
>
> > I agree with you. I exagerated a little here, but i was a little
> > iritated about Tomas atitude and his acid posts, not only in this
> > topic.
> > I reached his site, I see that he is a good programmer, but his
> > atitude ....
>
> > about jQuery quality, can't make a statement, I have coleagues who use
> > it and are happy with it.
> > I prefer Prototype. I don't know what programing rules broke Prototype
> > developers (if you have some links, discutions, please share), but
> > works for me.
>
> Perhaps this one:
Or this one:
A salient quote from one of Richard Cornford's posts in that thread:
"The Prototype.js approach results in code that cannot be
expected to work in any more browsers than those in which
it has been demonstrated to 'work', and so cannot even be
expected to 'work' with the future versions of ... those
browsers. This cannot be a viable approach to creating
cross-browser code, and it does not."
--
Rob
VK
> A salient quote from one of Richard Cornford's posts in that thread:
>
> "The Prototype.js approach results in code that cannot be
> expected to work in any more browsers than those in which
> it has been demonstrated to 'work', and so cannot even be
> expected to 'work' with the future versions of ... those
> browsers. This cannot be a viable approach to creating
> cross-browser code, and it does not."
The Richard Cornford's point of view was well expressed in this NG
many times. In his universe a program for MS-DOS has to seamlessly
migrate on 16bit GUI of any kind (not Windows only), then equally
seamlessly migrate to 32bit and 64bit GUI. Respectively when
programming in say MS-DOS the programmer has to foresee the whole
future line of OS development 10-20 years in advance. Any message of
the kind "This program requires ... to run" is a sign of a very bad
programming. I do respect personal philosophical schemes including
idealistic romanticism as well. Yet claiming it as a world-wide the
only correct programming pattern is Richard Cornford's personal choice
other have rights do no agree with.
humeniuc
> <http://groups.google.at/group/comp.lang.javascript/browse_frm/thread/...>
>
> Or this one:
>
Thanks, Gregor and RobG
Richard Cornford
> On Apr 15, 4:47 pm, Thomas 'PointedEars' Lahn wrote:
>> liketofindoutwhy wrote:
>>> I am learning more and more Prototype and Script.aculo.us
>>> and got the Bungee book... and wonder if I should get some
>>> books on jQuery (jQuery in Action, and Learning jQuery)
>>> and start learning about it too?
In the end it would be more productive to learn javascript and browser
scripting, and then you make your own mind up.
>>> [...]
>>
>> Prototype.js, and consequently everything based upon it, like
>> Script.aculo.us, is junk. The jQuery junk support forums are
>> elsewhere, too.
>
> So you mean Prototype and jQuery are both junk?
I didn't think that statement was ambiguous in any way.
> Can you give some points as to why you think so?
That is probably going to come down to understanding.
> For example, how else would you pass a
> call back function binding to the current scope,
Do you know what that means? It reads like the usual parroting of the
(lamentably) common misconception(or mislabelling) that scope is in some
way related to the value of the - this - keyword in javascript. While in
javascript scope is lexical and so (mostly) determined by the (structure
of the) source code and the - this - value is determined by how
functions/methods are call, and determined at runtime.
> such as processData.bind(this) ?
So it is the - this - value that concerns you, not scope at all.
But what sort of question are you asking? Javascript programmers know
what the - this - keyword will refer to at any point, and how to arrange
that the - this - keyword refers to specific objects when it is
necessary. You are not programming until you are in control of that sort
of thing.
As both of Prototype.js and JQuery are written in javascript it must be
possible to write javascript code that does anything and everything that
either are capable of.
> I kind of like the arr.each(function(x)
> { ... })
But is "like" enough of a reason? I have seen some horrendously
inefficient uses of function expressions in - each - and - forEach -
methods (including inside the JQuery source code). They seem to
encourage it, at lest where the author had not understood the
implications of what they are doing.
> or the arr.sort().uniq().join(" ") syntax.
That style of method chaining has been dogging javascript for years. It
is occasionally useful, but it does result in some very obscure source
code, which probably explains why I can think of no regular contributors
to this group who choose that style of coding.
And one of the consequences of the inherent obscurity of that style of
code is demonstrated in your example. It looks to me like the intention
of - uniq - would be to remove repetitious values from the array
(assuming the subject is an array) and it is unlikely that that method
has been written such that it benefits in any way from the array being
pre-sorted, but the sort method will almost certainly be more efficient
if any elements that are to be removed from the array are removed before
sorting.
Of course seeing and understanding the source code for those methods
would answer the question one way or the other.
But 'liking' superficial syntax and convenience methods are nowhere near
enough to mitigate for the observation (from the source code) that the
authors of those two libraries did not (and seemingly still do not)
understand javascript as a language or its application in browser
scripting.
Richard.
RobG
> On Apr 18, 3:03 am, RobG <rg...@iinet.net.au> wrote:
>
> > A salient quote from one of Richard Cornford's posts in that thread:
>
> > "The Prototype.js approach results in code that cannot be
> > expected to work in any more browsers than those in which
> > it has been demonstrated to 'work', and so cannot even be
> > expected to 'work' with the future versions of ... those
> > browsers. This cannot be a viable approach to creating
> > cross-browser code, and it does not."
>
> The Richard Cornford's point of view was well expressed in this NG
The snipped part your post utterly misrepresents Richard's often
expressed opinion. The funny thing is that only those familiar with
your posting style will have any idea what you were trying to say -
and they know enough about what you post to ignore it.
--
Rob
J.S.Criptoff
he's writing the second one - "Secrets of the JavaScript Ninja". He
was a javascript Guru. Now he is a javascript Ninja. Hey, it's time to
iconize him!
Your are invited to pray here:
http://ejohn.org/blog/state-of-the-secrets/
Thomas 'PointedEars' Lahn
> While c.l.j regulars are ridiculing John Resig's first javascript book
It does not need to be ridiculed. Many (if not most) of Resig's statements
are provably factually utterly wrong (and have been proven so here), so it
provides the ridiculousness by itself already.
> he's writing the second one - "Secrets of the JavaScript Ninja".
OMG!
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Gregor Kofler
> While c.l.j regulars are ridiculing John Resig's first javascript book
> he's writing the second one - "Secrets of the JavaScript Ninja". He
> was a javascript Guru. Now he is a javascript Ninja. Hey, it's time to
> iconize him!
I thought he was an "evangelist". Anyway, "What does with(){...} do and
why is it so useful?" will be one of the topics. PLUS: more class-like
implementations in JavaScript. I hope this book will finally put the
hipocrites of this group to shame.
> Your are invited to pray here:
> http://ejohn.org/blog/state-of-the-secrets/
Who knows? If you pray fervently enough, you might be in for a free
sample of "Secrets of the JavaScript Ninja". (Or the forthcoming "Way of
the JavaScript Samurai".)
Lasse Reichstein Nielsen
> Anyway, "What does with(){...} do
> and why is it so useful?" will be one of the topics.
It adds an object to the scope chain throughout its body.
This is one of the two ways to add a level to the scope chain, the other
being a function call.
Using "with" like a let-construct is dangerous, though.
function stepWatch(watch) {
for(var i = 0; i < watch; i++) {
with({i:i}) {
setTimeout(function(){alert(i + " of " + watch);}, i*1000);
}
}
}
stepWatch(5);
This appears to work fine in IE and Opera (where omitting the "with"
construct will alert "5" all the times).
Then someone runs it in Firefox, and it alerts:
0 of function watch() {
[native code]
}
The problem with the "with" construct is that you cannot control which
properties exist on the object. It differs between browsers (as
above), and it can be changed by other, misbehaved, libraries that
change Object.prototype.
So there, I'm looking forward to hearing why it's so useful :)
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Gregor Kofler
> The problem with the "with" construct is that you cannot control which
> properties exist on the object. It differs between browsers (as
> above), and it can be changed by other, misbehaved, libraries that
> change Object.prototype.
>
> So there, I'm looking forward to hearing why it's so useful :)
Let John respond:
Gopal:
would consider the "with" statement in JavaScript to be very harmful
rather than being useful.
John:
@Gopal: There's a ton of things in JavaScript that can be "considered
harmful". Since JavaScript is such an, extremely, flexible language you
can make mistakes all over the place and not catch it. I just think that
we need to have a better understanding of how the existing features work
to give us a clearer way to move forward and to work with what we have.
I hope this makes things *a lot* clearer.
John G Harris
>On Apr 17, 9:32 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
<snip>
>> > CNN (betaversionhttp://beta.cnn.com/) uses Prototype
>>
>> Super slow loading - about 50% of the 630kB payload is eaten up by JS
>> files...
>
>It takes 3sec on my 4Mb/sec downstream DSL for the initial page
>display where the download itself takes 0.39sec You may want to
>consider switching from Dial-Up to something more speedy ;-)
A lot of sailors have to use dial-up via INMARSAT. Do you have a cheery
word for them ?
John
--
John Harris
J.S.Criptoff
> The problem with the "with" construct is that you cannot control which
> properties exist on the object. It differs between browsers (as
> above), and it can be changed by other, misbehaved, libraries that
> change Object.prototype.
Almost the same situation with named FunctionExpression:
(function () {
var watch = 0;
(function f() {
alert(watch); //-> native code...
})();
})();
Lasse Reichstein Nielsen
> Almost the same situation with named FunctionExpression:
>
> (function () {
> var watch = 0;
> (function f() {
> alert(watch); //-> native code...
> })();
> })();
Wow! That's ... bad!
It seems Firefox decided to let the activation object inherit from
Object.prototype. There is nothing in the specification that requires
this, and, as you show us, it can give problems.
Neither Opera nor IE does this. Has it been bug-reported yet?
J.S.Criptoff
> It seems Firefox decided to let the activation object inherit from
> Object.prototype. There is nothing in the specification that requires
> this, and, as you show us, it can give problems.
No, Lasse, it is "special" object in scope chain created to keep
FunctionExpression name only (ES 13), no bug here.
Andrew Dupont
wrote:
> So what? They all have made the wrong design decision. Whether source code
> is good is not defined by those who use it but by the source code itself.
emissary in the human realm? (And I thought I had to read the
_comments_ to understand how code worked. What a fool I was.)
You're that guy who stubbornly insists that music is not a matter of
taste — who cannot suffer the fools who dare to question the status of
Rush's _Fly By Night_ as the best album of all time in any genre.
These philistines! They ply their ears with the bleating of musical
sheep!
> Yours is an "appeal to authority" fallacy, BTW.
You call foul for a logical fallacy against someone who was rebutting
your claim that two immensely popular JavaScript libraries are "junk"?
I count two right there: "appeal to ridicule" and "misplaced burden of
proof." You're the one asserting they're junk. The burden of proof is
yours.
> And an ad hominem fallacy in addition.
How dare he spoil the cordial tone. Someone asks a question about
Prototype and jQuery; you reply that they're junk, and snarkily imply
he's in the wrong place. He plainly asks you why you think they're
junk; instead of mounting an argument, you make a quip. Did this guy
piss in your cornflakes?
(I'm sure you've laid out your argument in the past, and have had to
repeat it several times – so there's no reason why you shouldn't slap
it on a web server somewhere and give someone a URL.)
Now, this is Usenet; flamewars and intellectual laziness are the rule,
not the exception. But if you're pointing out the logical fallacies of
others I can only assume you aspire to a higher plane of debate.
Cheers,
Andrew
AKS
J.S.Criptoff wrote:
> No, Lasse, it is "special" object in scope chain created to keep
> FunctionExpression name only (ES 13), no bug here.
"Special" object? No, it's not:
F();
function F() {
alert(watch); //-> native code...
};
AKS
> "Special" object? No, it's not:
Excuse me, I was mistaken!
Lasse Reichstein Nielsen
> No, Lasse, it is "special" object in scope chain created to keep
> FunctionExpression name only (ES 13), no bug here.
Indeed, by bad. It only occurs when the inner function expression is a
named function. It's not the activation object, and it is as specified
in the standard (which probably means that the standard should be
changed, becuause that's a bad choice!)
Richard Cornford
> J.S.Criptoff writes:
>
>> No, Lasse, it is "special" object in scope chain created
>> to keep FunctionExpression name only (ES 13), no bug here.
>
> Indeed, by bad. It only occurs when the inner function expression
> is a named function. It's not the activation object, and it is
> as specified in the standard (which probably means that the
> standard should be changed, becuause that's a bad choice!)
That does seem a bit of an oversight on the part of the authors of the
specification (possibly not seeing the full consequences of what they
were writing). On the other hand the infamous JScript(tm) bug where
using an Identifier with a function expression results in the creation
of an additional function object as a named property of the current
Variable object (and during variable insanitation) already means that
using Identifiers with function expression has inconsistent
consequences. So doing so was already a bad idea.
Richard.
Richard Cornford
> While c.l.j regulars are ridiculing John Resig's first
> javascript book he's writing the second one - "Secrets
> of the JavaScript Ninja".
That would not necessarily have to such a bad thing as it may at first
appear to be. The first book was published in 2006 and it is possible to
learn a great deal in two years. Granted I don't think that John Resig's
attitude will lend itself to facilitating his learning anything
effectively.
Richard.
Richard Cornford
> On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
>> So what? They all have made the wrong design decision. Whether
>> source code is good is not defined by those who use it but by
>> the source code itself.
>
> And the source code makes its divine message known through you,
> its emissary in the human realm? (And I thought I had to read
> the _comments_ to understand how code worked. What a fool I
> was.)
It is very often a characteristic of 'good' source code (at least in
higher level languages) that the code can easily be understood by
reading the source code.
However, the last significant discussion of the Prototype.js source code
that we had here (the link, via Google groups, to that discussion is in
one of the posts in this thread) showed that the authors of Protoype.js
obviously did not understand the code they were writing (instead finding
themselves victims of code that exhibited behaviour that conformed with
their expectations by no more than coincidence (but then only on the
browsers were they had observed that behaviour)). Under those
circumstances the code itself if more informative than the comments
because an author who does not understand the code they are writing
cannot comment it in an informative way.
> You're that guy who stubbornly insists that music is not a
> matter of taste - who cannot suffer the fools who dare to
> question the status of Rush's _Fly By Night_ as the best
> album of all time in any genre. These philistines! They ply
> their ears with the bleating of musical sheep!
>
>> Yours is an "appeal to authority" fallacy, BTW.
I didn't think that was an appeal to authority, more of an appeal to
bulk, in some sens.
> You call foul for a logical fallacy against someone who was
> rebutting your claim that two immensely popular JavaScript
> libraries are "junk"?
That wasn't a rebuttal, more of an excuse for using the code regardless
of any informed assessment of its quality.
> I count two right there: "appeal to ridicule" and "misplaced
> burden of proof." You're the one asserting they're junk. The
> burden of proof is yours.
<snip>
Where the 'proof' is already a matter of public record, and familiar to
anyone who has any more than superficial record of participating in this
group, there is no longer any burden of proof at all.
Still, if you want examples they are just a short download away.
Downloding the latest version of Prototype.js (1.6.0.2) I wondered how
long it would take me to find an example of something being done
sufficiently badly for that to be easily and unambiguously demonstrated.
The answer was under three seconds. During the first scroll through the
code, not even looking at most of the details, I noticed this:-
| if (Prototype.Browser.WebKit || Prototype.Browser.IE)
| Object.extend(String.prototype, {
| escapeHTML: function() {
| return this.replace(/&/g,'&')
| .replace(/</g,'<')
| .replace(/>/g,'>');
| },
| unescapeHTML: function() {
| return this.replace(/&/g,'&')
| .replace(/</g,'<')
| .replace(/>/g,'>');
| }
| });
- which is adding a couple of escaping/unescaping methods to the -
String.prototype - object based upon a condition. Seeing it I asked
myself whether the author had made the rookie mistake that every web
development novice always makes (and the thing I deliberately double
check every time I ask someone to write an escaping/unescaping function
for any purpose), and the answer was a very obvious "yes they have".
One of the arguments paraded in favour of these libraries is that they
are examined, worked on and used by very large numbers of people, and so
they should be of reasonably high quality because with many eyes looking
at the code obvious mistakes should not go unnoticed. My experience of
looking at code from the various 'popular' libraries suggests that this
is a fallacy, because (with the exception of YUI (for obvious reasons))
all of the 'popular' library contain numerous obviously stupid mistakes.
The problem probably being that it does not matter how many people may
look at, review or use, any particular piece of code, if none of them
understand what they are doing none of them are capable of spotting the
obvious mistakes.
In this case we have a very obviously stupid use of user agent string
based browser detection to make a decision that would be more logically
made with feature detection. That is, the attempt is to add two methods
to the - String.prototype - in environments were those methods do not
already exist. Obvioulsy the is a one-to-one relationship between -
String.prototype.escapeHTML - having trueness and an environment where
a - String.prototype.escapeHTML - has been implemented. While the
relationship between a user agent sting an a -
String.prototype.escapeHTML - method is at best tenuous, and certainly
not guaranteed to be comprehensive or continuous over time.
But that is not the rookie mistake I alluded to above. That mistake is
that the escaping and unescaping methods are not symmetrical. That is,
if you apply the second to the output of the first you will not always
end up with the character sequence you start with. I.E.:-
<script type="text/javascript">
alert('<'.escapeHTML().unescapeHTML()); //alerts "<"
alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<"
<script>
- and that is pretty bad by anyone's standards (except maybe VK's).
Richard.
J.S.Criptoff
wrote:
In two years? Are you kidding, Richard? John Resig gave a presentation
for the local ACM of Northeastern University and covered the basics of
javascript a few weeks ago. Weeks. Look at his slide, Richard:
Type coersion
0 == false
null == false
!"foo" == false
And listen to guru-ninja's explanation: "Zero is equal to false. Zero
gets coerced into becoming а boolean value... Same thing with
nulls...".
from 5:50
http://video.google.com/videoplay?docid=-7485992465859932389
Thomas 'PointedEars' Lahn
> Andrew Dupont wrote:
>> On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
>>> Yours is an "appeal to authority" fallacy, BTW.
>
> I didn't think that was an appeal to authority, more of an appeal to
> bulk, in some sens.
Quoting people who approve of something and concluding that therefore this
something must be good is the classical example for the logical fallacy of
appeal to authority, also known as "ipse dixit" ("he himself said it").
Unfortunately, out of general appreciation of the other person, several
regulars around here tend to fall victim to this fallacy as well, without
recognizing it. We should strive to avoid such fallacious arguments,
especially as they only weaken a good case when confronted with an argument
that is fallacious as well.
http://en.wikipedia.org/wiki/Appeal_to_authority
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Richard Cornford
>Richard Cornford wrote:
>> J.S.Criptoff wrote:
>>> While c.l.j regulars are ridiculing John Resig's first
>>> javascript book he's writing the second one - "Secrets
>>> of the JavaScript Ninja".
>> <snip>
>>
>> That would not necessarily have to such a bad thing as it may
That really should have been; "... have to be such a bad thing ..".
>> at first appear to be. The first book was published in 2006
>> and it is possible to learn a great deal in two years. Granted
>> I don't think that John Resig's attitude will lend itself to
>> facilitating his learning anything effectively.
>
> In two years? Are you kidding, Richard?
Not at all. The bulk of what I have learnt about javascript was learnt
in the period from 2002 to 2004. Two years is plenty of time, if you put
the effort in and are receptive to the idea that you really didn't know
it all to start with.
> John Resig gave a presentation for the local ACM of
> Northeastern University and covered the basics of
> javascript a few weeks ago. Weeks. Look at his slide,
> Richard:
>
> Type coersion
> 0 == false
> null == false
> !"foo" == false
>
> And listen to guru-ninja's explanation: "Zero is equal to
> false. Zero gets coerced into becoming ? boolean value...
> Same thing with nulls...".
<snip>
Well, I did say that his attitude would get in the of his potential to
learn. He dropped into a thread on this group with the subject
"prototype - Good/Bad/Why?", which commenced 15th February 2008 and in
which the section of his first book that reads:-
"In JavaScript, null, 0, '', false, and undefined are all equal (==)
to each other, since they all evaluate to false. This means that if
you use the code test == false, it will evaluate true if test is
also undefined or equal to null, which may not be what you want."
- and goes on to state that:-
"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined" - John Resig: Pro JavaScript Techniques. 2006
- was directly criticised for its demonstrably false statements about
javascript (and also the competence of the book's technical editor (who
apparently works for Google) as a result of letting those errors pass
uncorrected). If he had hung around and paid attention to his critics he
would not have been repeating that same mistake just a couple of weeks
ago. But then the code:-
| makeArray: function( array ) {
| var ret = [];
|
| // Need to use typeof to fight Safari childNodes crashes
| if ( typeof array != "array" )
| for ( var i = 0, length = array.length; i < length; i++ )
| ret.push( array[ i ] );
| else
| ret = array.slice( 0 );
|
| return ret;
| },
- was still in the last (1.2.3) release of JQuery more than six months
after John Resig had been directly asked to justify it during his
previous visit to this group. He did not attempt to justify it (which
would not have been that difficult if it could be justified at all [1]),
but apparently also did not grasp the reason for the criticism.
Interestingly I observed Matt Kruse (who is the nearest thing to a
supporter JQuery has among the regular contributors to this group, and
someone who can easily outgun anyone directly involved in JQuery
development when it comes to javascript) directly asked however was
responsible for the - if ( typeof array != "array" ) - code to own up to
it in a post on the JQuery development group. However, when I checked
back a week later to see if anyone had the intellectual integrity to own
up to their mistake I found that Matt's post had been deleted from the
group.
Well, we get used to the intellectual freedom of Usenet, where criticism
is just a matter of public record. While those more familiar with
blogging and (self?) moderated Google forums might see deleting their
critics as a satisfactory approach to avoiding realising their mistakes.
Richard.
[1] For those who need to be told; javascript primitives and native and
built in objects may only result in the strings 'string', 'undefined',
'object', 'function', 'number' and 'boolean' from a typeof operation
(with no known implementation bugs in this area). Host objects are
allowed to return any value (or even throw exceptions), such as when the
methods of ActiveX object result in the string 'unknown' when a typeof
operation is applied to them. So, if the code - if ( typeof array !=
"array" ) - makes any sense at all there must be an object property of a
host object in a browser (and since JQuery only works with the default
configurations of just four browser it must be one of those four
browsers) with a - slice - method that results in 'array' when a typeof
operation is applied to it. It should not be at all difficult to name
the object/property and browser/browser version in question, and so
justify code that otherwise looks like a long running mistake that is
being repeated in the face of direct criticism.
Richard Cornford
> Richard Cornford wrote:
>> Andrew Dupont wrote:
>>> On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
>>>> Yours is an "appeal to authority" fallacy, BTW.
>>
>> I didn't think that was an appeal to authority, more of an
>> appeal to bulk, in some sens.
>
> Quoting people who approve of something and concluding that
> therefore this something must be good is the classical example
> for the logical fallacy of appeal to authority, also known as
> "ipse dixit" ("he himself said it").
It is certainly an appeal to something, but it often feels as if that
something is not "authority" much of the time. After all, why should
NASA, Apple or CNN be considered authorities on web development at all.
You would not cite someone who was perceived as having web development
expertise in support of opinions on space exploration, computer hardware
design or news broadcasting so why attempt to do so the other way
around.
And Google is just a joke in any list of 'authorities' on web
development. I noticed at the beginning of last week that they have
(after just half a decade) finally managed to improve the accuracy of
their adding-up code on Google groups to an accuracy better than the
previous plus or minus 60% (and so radically re-arrange their 'all time
top posters' list for comp.lang.javascript), and the next day I tried to
show someone that they had done something about that code only to find
that the page containing the list was no longer working at all (and
stayed non-functional for the rest of the week). Their code is clearly
such a mess that whenever they try to fix one of its faults it promptly
unravels somewhere else.
> Unfortunately, out of general appreciation of the other
> person, several regulars around here tend to fall victim
> to this fallacy as well, without recognizing it.
Yes, and it seems to be getting to be me who keeps being cited as an
authority. I suppose that I probably should not worry about that from a
personal point of view because for each opinion of mine that is
accurately represented there will also be reasoned statement of
justification for that position somewhere on the public record. Though
it is perhaps a pity that reasoned arguments are apparently not seen as
standing or falling independently of any 'authority' that makes them,
and so should be presented in themselves.
> We should strive to avoid such fallacious arguments,
> especially as they only weaken a good case when confronted
> with an argument that is fallacious as well.
That would be good. But I can certainly see how the Prototype.js/JQuery
argument is starting to get so old that people are reverting to
knee-jerk generalisation as an alternative to going over it all again.
Richard.
VK
As a person: "Good and safe trip to all of you!".
As a web developer: nothing. Unless of course some particular project
will require to accommodate the content delivery to the most thin
clients and/or most narrow bandwidth. In the latter case we will do
anything possible within the budget for that: from light weighted HTML
to WML. But no one will change the Web in whole neither for Inmarsat
nor for GSM cell phone surfers.
Andrew Dupont
wrote:
First off, full disclosure: I am a Prototype developer, and I know
John Resig well and have immense respect for his library. I don't seek
to change anyone's mind about libraries; I only want to ensure that
dislike thereof is driven by thoughtful deliberation and/or a core
philosophy difference. I welcome any constructive criticism and agree
to disagree about the rest.
>
> > You call foul for a logical fallacy against someone who was
> > rebutting your claim that two immensely popular JavaScript
> > libraries are "junk"?
>
> That wasn't a rebuttal, more of an excuse for using the code regardless
> of any informed assessment of its quality.
To be clearer: I saw it as an argument for why Thomas owned the burden
of proof. If these libraries have won legitimacy on the mainstream
Web, then the opinion that they are shoddy is held by a minority, and
they obviously need to do more persuading.
Again, I worry about matters of taste being presented as facts. I
don't mean to say that all statements need to be prepended with "In my
opinion," but Thomas was using his own taste to render judgement on a
thread and shoo away its originator. I think it's far more
constructive to say "Most of us are not library fans, so you're
unlikely to find useful answers here," then point the way to the
jQuery mailing list. That'd accomplish the same goal with far less
drama.
>
> > I count two right there: "appeal to ridicule" and "misplaced
> > burden of proof." You're the one asserting they're junk. The
> > burden of proof is yours.
>
> <snip>
>
> Where the 'proof' is already a matter of public record, and familiar to
> anyone who has any more than superficial record of participating in this
> group, there is no longer any burden of proof at all.
Perhaps the comp.lang.javascript FAQ needs an entry for this, then. A
large portion of those who post on this newsgroup aren't participants
or even lurkers; they come by only when they have problems. They can't
be expected to catch up on the backstory.
> In this case we have a very obviously stupid use of user agent string
> based browser detection to make a decision that would be more logically
> made with feature detection.
Actually, no — no browser implements String#(un)escapeHTML, so feature
detection would be pointless. We define that function earlier in the
file, but redefine them for WebKit and IE because the String#replace
approach is much, much faster in these two browsers (but much, much
slower in FF and Opera).
To be sure, there are other UA sniffs in Prototype that hard-liners
would decry as unnecessary. I personally try to avoid sniffing
wherever possible, but there are some instances in which a capability
check is either impossible or prohibitively complicated. (The line
between "acceptably complicated" and "prohibitively complicated" is
defined by the individual.)
>
> But that is not the rookie mistake I alluded to above. That mistake is
> that the escaping and unescaping methods are not symmetrical. That is,
> if you apply the second to the output of the first you will not always
> end up with the character sequence you start with. I.E.:-
>
> <script type="text/javascript">
> alert('<'.escapeHTML().unescapeHTML()); //alerts "<"
> alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<"
> <script>
>
> - and that is pretty bad by anyone's standards (except maybe VK's).
I agree with you on this one. A bug was filed on this not too long
ago; I believe a fix has been checked into trunk and will be in the
next release.
Cheers,
Andrew
Richard Cornford
> On Apr 19, 11:02 am, Richard Cornford wrote:
>
> First off, full disclosure: I am a Prototype developer,
> and I know John Resig well and have immense respect for
> his library.
> I don't seek to change anyone's mind about libraries; I only
> want to ensure that dislike thereof is driven by thoughtful
> deliberation and/or a core philosophy difference. I welcome
> any constructive criticism and agree to disagree about the
> rest.
Who is going to be deciding what 'constructive' means in this context?
>>> You call foul for a logical fallacy against someone who was
>>> rebutting your claim that two immensely popular JavaScript
>>> libraries are "junk"?
>>
>> That wasn't a rebuttal, more of an excuse for using the code
>> regardless of any informed assessment of its quality.
>
> To be clearer: I saw it as an argument for why Thomas owned
> the burden of proof. If these libraries have won legitimacy
> on the mainstream Web,
That is an 'if'. Did they win legitimacy or are they just the next
evolution of the copy-and-paste script collections that were mainstay of
less commencement web developers of 5 or 6 years ago?
> then the opinion that they are shoddy is held by a minority,
Most informed quality assessments in technical areas will be held by a
minority.
> and they obviously need to do more persuading.
You mean that if someone is in a 'minority' then they must be wrong?
That is hardly an attitude that would allow progress through the
adoption of new ideas.
> Again, I worry about matters of taste being presented
> as facts.
You have not demonstrated that these are questions of taste. The last
time we discussed the prototype.js code here in detail (which was
version 1.6, in November last year) it demonstrated evidence of or its
authors (collectively, as nobody had corrected the code) not
understanding how the code they were writing was going to behave. Seeing
that brings everything into question, form the original design concepts
to every detail of its implementation. And those are not then questions
of taste but the inevitable consequence of evident ignorance among its
developers.
> I don't mean to say that all statements need to be
> prepended with "In my opinion," but Thomas was using his
> own taste to render judgement on a thread and shoo away
> its originator.
How do you know that? It seems likely to me that Thomas was using his
memory of the many (more or less detailed) discussions of Prototype.js
code that have happened here over the past few years to inform a general
assessment of the code.
> I think it's far more constructive to say "Most of us
> are not library fans, so you're unlikely to find useful
> answers here,"
That would not be a true statement (at least the second part of it, and
the first part if you take the word 'library' in its most general
sense).
> then point the way to the jQuery mailing list.
I have read enough of posts on the JQuery groups to be pretty sure
nobody is likely to much understanding their either. There is too much
of the blind leading the blind (and a huge proportion of questions never
seem to get answered at all).
> That'd accomplish the same goal with far less
> drama.
Accomplish which goal? Don't you think the OP, if he/she is still
reading this, has not learnt a great deal from this discussion despite
its initial response. There is a lot to be said for the uncensored
exchange of ideas in public.
>>> I count two right there: "appeal to ridicule" and "misplaced
>>> burden of proof." You're the one asserting they're junk. The
>>> burden of proof is yours.
>>
>> <snip>
>>
>> Where the 'proof' is already a matter of public record, and
>> familiar to anyone who has any more than superficial record
>> of participating in this group, there is no longer any
>> burden of proof at all.
>
> Perhaps the comp.lang.javascript FAQ needs an entry for this,
> then.
It has been discussed, and a number of draft entries proposed. But there
remains some dispute as to what an appropriate response to the question
should be. From the point of view of someone wanting a better
understanding of javascript or browser scripting who just happens to be
using some 'popular' library then they really would get the best answers
to their questions here, if they could present their questions in
isolation (from all of the unrelated and irrelevant stuff that those
libraries contain).
> A large portion of those who post on this newsgroup aren't
> participants or even lurkers;
If they post questions then they are participants.
> they come by only when they have problems. They can't
> be expected to catch up on the backstory.
They can. Expecting someone to do a few web searches before they ask to
be spoon fed is not too unreasonable.
>> In this case we have a very obviously stupid use of user
>> agent string based browser detection to make a decision that
>> would be more logically made with feature detection.
>
> Actually, no - no browser implements String#(un)escapeHTML,
> so feature detection would be pointless. We define that
> function earlier in the file,
Yes, I noticed the other two assignments to the - String.prototype -
later and realised that I was wrong about that.
> but redefine them for WebKit and IE because the String#replace
> approach is much, much faster in these two browsers (but much,
> much slower in FF and Opera).
Can you post a test-case that demonstrates that assertion? Historically
IE has been renowned for its lousy performance with string
manipulation, while Mozilla outperformed everyone else in that area.
But I noticed that the other two escaping/unescaping methods are nothing
like analogous to the two I posted. That is pretty bad in itself because
it means that the same source code is going to have different outcomes
depending on which browser it encounters, and the only way to avoid
falling foul of that would be to explicitly test any application using
the code on each and every browser and with a sufficiently divers set of
data to expose the situations where those inconsistencies might be
problematic. And that is something that is unlikely to actually happen
even in organisations that do do formal QA. After all, you missed the
fact that Safari/IE versions were defective yourselves so how could you
expect web developers who know no more than how to use a library find
the potential issues (or understand them if they did manifest
themselves).
It would be safer to forget about performance in this respect and just
use one set of escaping and unescaping methods. After all, these methods
are not used by the library itself, and are unlikely to be that heavily
used in applications.
> To be sure, there are other UA sniffs in Prototype that
> hard-liners would decry as unnecessary.
It is not 'unnecessary' that is the questionable aspect of browser
sniffing, but rather that it is technically baseless and demonstrably
ineffective.
<snip>
>> But that is not the rookie mistake I alluded to above. That
>> mistake is that the escaping and unescaping methods are not
>> symmetrical. That is, if you apply the second to the output
>> of the first you will not always end up with the character
>> sequence you start with. I.E.:-
>>
>> <script type="text/javascript">
>> alert('<'.escapeHTML().unescapeHTML()); //alerts "<"
>> alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<"
>> <script>
>>
>> - and that is pretty bad by anyone's standards (except maybe
>> VK's).
>
> I agree with you on this one.
But I suppose that you would not agree that being able to find an
obvious rookie mistake in less then three seconds of looking (at a
library that is already a good few years old) tends to support the
"junk" assessment.
> A bug was filed on this not too long ago; I believe a
> fix has been checked into trunk and will be in the
> next release.
Well, it is a pretty simple fix, and I notice that the subject of my
last substantial criticism of the prototype's code has also been
removed.
Richard.
Thomas 'PointedEars' Lahn
> Lasse Reichstein Nielsen meinte:
>> The problem with the "with" construct is that you cannot control which
>> properties exist on the object. It differs between browsers (as
>> above), and it can be changed by other, misbehaved, libraries that
>> change Object.prototype.
>>
>> So there, I'm looking forward to hearing why it's so useful :)
>
> Let John respond:
>
> Gopal:
> would consider the "with" statement in JavaScript to be very harmful
> rather than being useful.
>
> John:
> @Gopal: There's a ton of things in JavaScript that can be "considered
> harmful". Since JavaScript is such an, extremely, flexible language you
> can make mistakes all over the place and not catch it. I just think that
> we need to have a better understanding of how the existing features work
> to give us a clearer way to move forward and to work with what we have.
>
> I hope this makes things *a lot* clearer.
Unfortunately, your "this speaks for itself" statement is too ambiguous
to stand as an argument by itself. What exactly are you trying to say here?
beegee
wrote:
> beegee wrote:
> For that matter, at least JavaScript[tm] *is* a compiled language like Java.
> Don't confuse prompt execution with no-compilation.
Uh, no. Do you understand what compilation is? I mean, there are
javascript compilers but as far as I've heard, none in a browser yet.
> I think you miss the point. YUI is *supposedly* only "more like
> 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
> that its developers *supposedly* knew enough about the programming languages
> to unleash their full potential without having to resort to inefficient and
> error-prone detours of inventing "classes" and "initializers" where there
> are already prototypes and constructors.
You certainly do like to argue, don't you. It takes quite a talent to
obfuscate agreement to point of it sounding like disagreement.
Bob
Gregor Kofler
> Unfortunately, your "this speaks for itself" statement is too ambiguous
> to stand as an argument by itself. What exactly are you trying to say here?
I can only think of one advantage of with - saves some typing (and
script size). There might be others I don't know of. However, I also
know about the problem with with because of breaking the scope chain
(perhaps that's Gopal meant with his comment). There might be others I
don't know of.
Anyway, I expect that somebody claiming to be an "evangelist", "guru" or
"ninja" advertising the usefulness of "with", comes up with a more
substantial response than ...this. Well, maybe he doesn't want to give
away the best parts of the book.
Thomas 'PointedEars' Lahn
> On Apr 16, 12:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> beegee wrote:
>> For that matter, at least JavaScript[tm] *is* a compiled language like
>> Java. Don't confuse prompt execution with no-compilation.
>
> Uh, no. Do you understand what compilation is?
Yes, do you?
> I mean, there are javascript compilers but as far as I've heard, none in
> a browser yet.
There are JIT-compilers.
>> > I think you miss the point. YUI is *supposedly* only "more like
>> > 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
>> > that its developers *supposedly* knew enough about the programming languages
>> > to unleash their full potential without having to resort to inefficient and
>> > error-prone detours of inventing "classes" and "initializers" where there
>> > are already prototypes and constructors.
>
> You certainly do like to argue, don't you. It takes quite a talent to
> obfuscate agreement to point of it sounding like disagreement.
We don't have an agreement here.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn meinte:
>> Unfortunately, your "this speaks for itself" statement is too ambiguous
>> to stand as an argument by itself. What exactly are you trying to say here?
>
I see, and I agree with you here. Thanks for your explanation.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Lasse Reichstein Nielsen
> If these libraries have won legitimacy on the mainstream
> Web, then the opinion that they are shoddy is held by a minority, and
> they obviously need to do more persuading.
There is no contradiction between the two opinions. Something can
easily win ligitimacy and still be shoddy.
In this particular case, I believe libraries like Prototype and JQuery
to be distruptive technologies (q.v.). I.e., they *are* qualitatively
inferior to doing things the hard (old) way. However, they work
/adequately/ for many things, and they allow people with less skill
than would otherwise be necessary to create pages that serve their
needs. I.e., they are /enabling/ without being perfect.
People here will keep complaining about the shoddy quality of
libraries while that quality, slowly, increases. This goes on until
the time when libraries have won, and anybody not using them is
putting themselves at a disadvantage.
Richard Cornford
> Andrew Dupont writes:
>
>> If these libraries have won legitimacy on the mainstream
>> Web, then the opinion that they are shoddy is held by a minority,
>> and they obviously need to do more persuading.
>
> There is no contradiction between the two opinions. Something can
> easily win ligitimacy and still be shoddy.
And then there is the question of what constitutes "legitimacy" in the
first place. Were the copy-and-paste code collections of the last decade
illegitimate? Or endemic bad practices such as eval-ing runtime
constructed property accessor strings? Some would answered with a
resounding 'yes', while the people using them would probably have
disagreed.
> People here will keep complaining about the shoddy quality of
> libraries while that quality, slowly, increases.
If complaining was the only thing that went on here then that would end
up being futile and pointless. But over the years the discussions of the
many inherent problems with general purpose libraries had resulted in
some useful ideas about how to set about creating a code-base that could
offer high levels of code re-use, and a relatively low entry level,
while mitigating the problems inherent in the current approaches.
As to "slowly, increasing"; that is happening, at minimum because the
authors of those libraries cannot avoid becoming better informed about
how javascript works at time goes on. The really very obviously bad
aspects of their original cod do eventually get weeded out. But there is
a limit to how far that can go because while these things have 'users'
who expect ongoing support, bug fixes and updates for new browsers there
is never a possibility of going back and re-visiting the fundamental
design of the library's API. And if the original design was done at a
time when the original authors were writing code that was amenable to
improvements in its internal quality the odd are extremely good that
those shortcomings also manifested themselves in the API design itself.
So Prototype.js and QUery authors are struggling to mitigate the poor
performance that their code exhibits, and realistically can probably
nearly double its actual performance, but that is it. Aspects of the
original library design place a fixed cap on what can be achieved even
if all of the internal details were rendered optimal.
> This goes on until the time when libraries have won, and
> anybody not using them is putting themselves at a
> disadvantage.
There is no disadvantage from understanding javascript. In the event
that I was put in a position of being forced to use any of these
'popular' libraries the ability to understand how they work internally
would be a huge advantage in actually using them. Though that is
extremely unlikely to happen where I work now because none of the
existing popular libraries perform anywhere near fast enough for the web
applications I work on, and they never could.
Richard.
kangax
wrote:
> There is no disadvantage from understanding javascript. In the event
> that I was put in a position of being forced to use any of these
> 'popular' libraries the ability to understand how they work internally
> would be a huge advantage in actually using them. Though that is
> extremely unlikely to happen where I work now because none of the
> existing popular libraries perform anywhere near fast enough for the web
> applications I work on, and they never could.
Is it possible to see the above mentioned web applications?
Thanks,
kangax
beegee
wrote:
> beegee wrote:
> > Uh, no. Do you understand what compilation is?
>
> Yes, do you?
Transforming an english-like higher level programming language coded
program into a lower-level programming language coded program for the
benefits of speed and size.
> > I mean, there are javascript compilers but as far as I've heard, none in
> > a browser yet.
>
> There are JIT-compilers.
And what lower level language or instruction set are these JIT-
compilers compiling Javascript into to? Setting up a symbol table and
transforming to more efficient Javascript in the pre-processing pass
of Javascript is not compiling. All modern interpreters do this.
Again, there are real compilers for Javascript (Rhino) but they are
not in browsers yet although it's possible that FF 3.0 has one.
> >> > I think you miss the point. YUI is *supposedly* only "more like
> >> > 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
> >> > that its developers *supposedly* knew enough about the programming languages
> >> > to unleash their full potential without having to resort to inefficient and
> >> > error-prone detours of inventing "classes" and "initializers" where there
> >> > are already prototypes and constructors.
>
> > You certainly do like to argue, don't you. It takes quite a talent to
> > obfuscate agreement to point of it sounding like disagreement.
>
> We don't have an agreement here.
Really? Are you saying the creators of YUI do not know enough about
javascript to avoid the pitfalls of JQuery and Prototype? I'm the
first to admit that YUI has some speed and object model problems but
I'm not sure that mocking the libary for only *supposedly* being
better than the others without some kind of specifics is really a
point view.
Bob
Zeroglif
> On Apr 20, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > beegee wrote:
> > > Uh, no. Do you understand what compilation is?
>
> > Yes, do you?
>
> Transforming an english-like higher level programming language coded
> program into a lower-level programming language coded program for the
> benefits of speed and size.
Brendan Eich (JavaScript):
"Client JavaScript reads source from SCRIPT tag contents, but compiles
it into an internal bytecode for faster interpretation."
Eric Lippert (JScript):
"JScript Classic acts like a compiled language in the sense that
before any JScript Classic program runs, we fully syntax check the
code, generate a full parse tree, and generate a bytecode. We then run
the bytecode through a bytecode interpreter. In that sense, JScript is
every bit as "compiled" as Java. The difference is that JScript does
not allow you to persist or examine our proprietary bytecode. Also,
the bytecode is much higher-level than the JVM bytecode -- the JScript
Classic bytecode language is little more than a linearization of the
parse tree, whereas the JVM bytecode is clearly intended to operate on
a low-level stack machine."
Andrew Dupont
wrote:
> Who is going to be deciding what 'constructive' means in this context?
Each individual on his own. Or, in other words: say what you want to
say, and I'll brush off anything I think is unwarranted. I'm not
setting conditions for prior restraint here.
> You mean that if someone is in a 'minority' then they must be wrong?
> That is hardly an attitude that would allow progress through the
> adoption of new ideas.
I never said anything of the sort. I said the minority need to do more
_persuading_. You stated that these libraries were junk as though it
were common knowledge. Clearly it isn't common knowledge.
> You have not demonstrated that these are questions of taste. The last
> time we discussed the prototype.js code here in detail (which was
> version 1.6, in November last year) it demonstrated evidence of or its
> authors (collectively, as nobody had corrected the code) not
> understanding how the code they were writing was going to behave. Seeing
> that brings everything into question, form the original design concepts
> to every detail of its implementation. And those are not then questions
> of taste but the inevitable consequence of evident ignorance among its
> developers.
I hold that any technology decision is a question of taste. There is
no objective "better" in the sense of Ruby vs. Python, or vi vs.
emacs; there is only the subjective "better" — whichever best serves
the user's own needs.
Naturally, this does _not_ mean that everything is relative, or that
it's not worth having passionate arguments thereabout. I implied as
much in my music analogy: friends argue among themselves over which
band is "better," but they all realize that taste is the ultimate
arbiter. These arguments become tiresome only when people dig trenches
and start speaking in absolutes.
> How do you know that? It seems likely to me that Thomas was using his
> memory of the many (more or less detailed) discussions of Prototype.js
> code that have happened here over the past few years to inform a general
> assessment of the code.
And I submit that is a matter of taste. Bugs are bugs, of course, and
we welcome bug reports. But you've gone further than that; you've
inferred from "evidence" that code in Prototype does not do what its
author means for it to do.
> > I think it's far more constructive to say "Most of us
> > are not library fans, so you're unlikely to find useful
> > answers here,"
>
> That would not be a true statement (at least the second part of it, and
> the first part if you take the word 'library' in its most general
> sense).
Then write your own words. That way they'll be _from the heart_. You
know the point I'm trying to make.
>
> > then point the way to the jQuery mailing list.
>
> I have read enough of posts on the JQuery groups to be pretty sure
> nobody is likely to much understanding their either. There is too much
> of the blind leading the blind (and a huge proportion of questions never
> seem to get answered at all).
>
> > That'd accomplish the same goal with far less
> > drama.
>
> Accomplish which goal? Don't you think the OP, if he/she is still
> reading this, has not learnt a great deal from this discussion despite
> its initial response. There is a lot to be said for the uncensored
> exchange of ideas in public.
The word "censorship" doesn't come within miles of this thread. I do
not own a telecommunications company; I don't have the means or
authority to "censor" anyone.
I can only imagine the OP was interested in the free exchange of ideas
when he asked you why you thought jQuery and Prototype were junk. I'm
arguing that he'd have learned far more from a link to a page called
"Why I, Richard Cornford, Think Prototype and jQuery Are Junk" than
from this low-signal, high-noise snark-off.
> > Perhaps the comp.lang.javascript FAQ needs an entry for this,
> > then.
>
> It has been discussed, and a number of draft entries proposed. But there
> remains some dispute as to what an appropriate response to the question
> should be. From the point of view of someone wanting a better
> understanding of javascript or browser scripting who just happens to be
> using some 'popular' library then they really would get the best answers
> to their questions here, if they could present their questions in
> isolation (from all of the unrelated and irrelevant stuff that those
> libraries contain).
That last sentence is the answer to such a FAQ. Even a link to that
question and answer would be more helpful than what has happened in
this thread.
> > A large portion of those who post on this newsgroup aren't
> > participants or even lurkers;
>
> If they post questions then they are participants.
I mean that they weren't participants before their first post. Many
posters, I would venture, only come here when they need help, and
therefore aren't already familiar with the quirks of the community.
> > they come by only when they have problems. They can't
> > be expected to catch up on the backstory.
>
> They can. Expecting someone to do a few web searches before they ask to
> be spoon fed is not too unreasonable.
Please search this newsgroup for the terms "Prototype" and/or "jQuery"
and see how quickly you find a well-summarized critique of either
library.
> >> In this case we have a very obviously stupid use of user
> >> agent string based browser detection to make a decision that
> >> would be more logically made with feature detection.
>
> > Actually, no - no browser implements String#(un)escapeHTML,
> > so feature detection would be pointless. We define that
> > function earlier in the file,
>
> Yes, I noticed the other two assignments to the - String.prototype -
> later and realised that I was wrong about that.
>
> > but redefine them for WebKit and IE because the String#replace
> > approach is much, much faster in these two browsers (but much,
> > much slower in FF and Opera).
>
> Can you post a test-case that demonstrates that assertion? Historically
> IE has been renowned for its lousy performance with string
> manipulation, while Mozilla outperformed everyone else in that area.
I don't have a test-case. The change was made one year ago by Thomas
Fuchs [1]. You're welcome to ask him, though I suspect he'll punch me
in the sternum for having dragged him into this.
>
> But I noticed that the other two escaping/unescaping methods are nothing
> like analogous to the two I posted. That is pretty bad in itself because
> it means that the same source code is going to have different outcomes
> depending on which browser it encounters, and the only way to avoid
> falling foul of that would be to explicitly test any application using
> the code on each and every browser and with a sufficiently divers set of
> data to expose the situations where those inconsistencies might be
> problematic. And that is something that is unlikely to actually happen
> even in organisations that do do formal QA. After all, you missed the
> fact that Safari/IE versions were defective yourselves so how could you
> expect web developers who know no more than how to use a library find
> the potential issues (or understand them if they did manifest
> themselves).
Nothing I say in our defense will satisfy you, because you seem to
want a level of certitude that I can't guarantee. I could say that we
have extensive unit tests, but clearly they were not extensive enough
to catch the bug that you pointed out — though that bug was noticed in
the wild, submitted to our tracker, and patched, and more unit tests
were added in the process. This is how open-source software works.
I can't guarantee that any of us will write bug-free code on the first
pass, any more than you can guarantee that you won't spell another
word incorrectly for the rest of your life. instead, we have a testing
process meant to ferret out as many self-introduced bugs as possible.
When that fails, we rely on the community to file tickets. No doubt
you have rolled your eyes by now, so I'll just move on.
>
> It would be safer to forget about performance in this respect and just
> use one set of escaping and unescaping methods. After all, these methods
> are not used by the library itself, and are unlikely to be that heavily
> used in applications.
>
> > To be sure, there are other UA sniffs in Prototype that
> > hard-liners would decry as unnecessary.
>
> It is not 'unnecessary' that is the questionable aspect of browser
> sniffing, but rather that it is technically baseless and demonstrably
> ineffective.
You haven't demonstrated that anything is baseless or ineffective;
you've only revealed a different set of priorities. You'd rather have
100% guaranteed behavior even if it meant a wildly-varying performance
graph across browsers. I'd rather have the reverse.
> But I suppose that you would not agree that being able to find an
> obvious rookie mistake in less then three seconds of looking (at a
> library that is already a good few years old) tends to support the
> "junk" assessment.
The check-in is only one year old. It is Thomas's bug, but he is no
rookie, so I can only surmise that we all make silly mistakes
sometimes. Bad luck for him that he managed to stumble upon your
Shibboleth Bug(TM).
> > A bug was filed on this not too long ago; I believe a
> > fix has been checked into trunk and will be in the
> > next release.
>
> Well, it is a pretty simple fix, and I notice that the subject of my
> last substantial criticism of the prototype's code has also been
> removed.
We listen to criticism, we read bug reports, and we constantly search
for ways to improve the feedback loop. So does John Resig, by the way,
so I'd suggest you file a bug on jQuery's Trac about the "makeArray"
mistake.
Cheers,
Andrew
Matt Kruse
wrote:
> Interestingly I observed Matt Kruse (who is the nearest thing to a
> supporter JQuery has among the regular contributors to this group, and
> someone who can easily outgun anyone directly involved in JQuery
> development when it comes to javascript)
Wow, given your view of the jQuery dev team, I'm not sure if that's
even close to a compliment ;)
> directly asked however was
> responsible for the - if ( typeof array != "array" ) - code to own up to
> it in a post on the JQuery development group. However, when I checked
> back a week later to see if anyone had the intellectual integrity to own
> up to their mistake I found that Matt's post had been deleted from the
> group.
If you're referring to this point:
http://groups.google.com/group/jquery-dev/msg/54b54712bd48ec83
then I can still find it.
Unfortunately, it hasn't generated any further discussion as I thought
it certainly warranted.
It's this kind of indifference about truly embarrassing code in the
jQuery source that I find most troubling.
They seem to be more interested in adding a new CSS3 selector or
saving 20 bytes by condensing some code than in correcting bad
programming practices.
I think John Resig loves Javascript and is probably learning more
about it as time goes on, but I suspect that his primary goal of
evangelizing jQuery is to enable the writing of more books and
attending more speaking engagements. Otherwise I can't comprehend why
some of these issues haven't gotten instant attention as I believe
they deserve.
Matt Kruse
Matt Kruse
> We listen to criticism, we read bug reports, and we constantly search
> for ways to improve the feedback loop. So does John Resig, by the way,
> so I'd suggest you file a bug on jQuery's Trac about the "makeArray"
> mistake.
I know nothing about Prototype's "feedback loop" but I'll say that my
impression of the jQuery loop has been that it is very fond of praise
and quick to dismiss or ignore genuine critiques about its core code
or design decisions.
I've made a number of attempts to make suggestions that I consider to
be no-brainers... getting rid of unnecessary browser sniffs,
optimizing loops which are extremely inefficient, making the
isFunction() function work more more closely to how it was
(misguidedly) intended, removing some code that is completely
unnecessary (makeArray), and reporting some bugs.
I've gotten a lackluster response to most posts, even though I would
consider some of these issues to be extremely important in cleaning up
the jQuery code, making it faster, and improving its overall quality.
I'm quite fond of much of the API that jQuery offers, the coding style
that it often enables, and the ease with which it enables new/amateur
developers to create working code in the right environments. If I had
the time and interest, I would probably be inclined to branch the code
into something more solid, fix many of the issues that exist, and
remove some of the overloading that makes the API kind of a mess.
But since I lack both the time and interest, I'm still trying to push
the jquery dev team into improving the code and hopefully bringing
jQuery up to par as a library that can withstand the scrutiny of
experienced js developers. Even if they would still not choose to use
it.
Matt Kruse
dhtml
wrote:
> Andrew Dupont wrote:
> > On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
> One of the arguments paraded in favour of these libraries is that they
> are examined, worked on and used by very large numbers of people, and so
> they should be of reasonably high quality because with many eyes looking
> at the code obvious mistakes should not go unnoticed. My experience of
> looking at code from the various 'popular' libraries suggests that this
> is a fallacy, because (with the exception of YUI (for obvious reasons))
Not obvious.
There's plenty of bugs YUI. A good number of them are reported in the
bugtracker (public) yet others are reported on the Yahoo internal bug
tracker (Bugzilla). Others may still be unfiled.
I don't 100% agree that the problem is not that the authors aren't
smart enough. A lot of these problems come from the process. Things
like having one guy own such-such piece of code, or the code freezes.
Or testing the happy path of maybe 20% of an object's methods.
> all of the 'popular' library contain numerous obviously stupid mistakes.
Including YUI.
They also have bug trackers. As Andrew pointed out, Prototype does
too.
A fix for the bug that was demonstrated seems to be by simply putting
the & last.
String.prototype.unescapeHTML = function() {
return this.replace(/</g,'<')
.replace(/>/g,'>')
.replace(/&/g,'&');
};
That would need to be tested out though.
Right?
Garrett
> Richard.
beegee
Thanks for the quotes. I thought, at first, from reading them that I
had been totally wrong about compilation of javascript. Then I read
deeper in the second quote about what the byte code is. And really,
it is not a true compilation. It is still a first pass optimization.
In fact I wouldn't be surprised if the same machine that can interpret
unprocessed javascript, interprets the bytecode.
Bob
Thomas 'PointedEars' Lahn
> Thanks for the quotes. I thought, at first, from reading them that I had
> been totally wrong about compilation of javascript. Then I read deeper
> in the second quote about what the byte code is. And really, it is not a
> true compilation. It is still a first pass optimization.
Winding around your error, are you? It is true compilation, as true as
byte-code compilation in Java is, for example.
> In fact I wouldn't be surprised if the same machine that can interpret
> unprocessed javascript, interprets the bytecode.
Bytecode is platform-independent, of course, because a Virtual Machine
interprets it. As I have said, in that sense at least JavaScript[tm],
and as it turns out JScript also, are compiled languages.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
VK
wrote:
> Bytecode is platform-independent, of course, because a Virtual Machine
> interprets it. As I have said, in that sense at least JavaScript[tm],
> and as it turns out JScript also, are compiled languages.
???
What is interpreted language then for you? Read next line of code -
Parse for token - Create internal code - Execute - Forgot this code -
Cleared the memory - Moved to the next line? Something like that?
There is no such engine since Enigma and Cyclometer at least :-)
Javascript is being stored and delivered to the engine in the raw text
source code format. The engine naturally compiles it to be able to use
so the engine works with compiled code - but Javascript is not a
compiled language. Try to see the difference, if you can.
P.S. JScript.NET _is_ a compiled language.
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Bytecode is platform-independent, of course, because a Virtual Machine
>> interprets it. As I have said, in that sense at least JavaScript[tm],
>> and as it turns out JScript also, are compiled languages.
>
Please spare us your fantasies about what other people might think. Thank
you in advance.
> Javascript is being stored and delivered to the engine in the raw text
> source code format. The engine naturally compiles it to be able to use
> so the engine works with compiled code - but Javascript is not a
> compiled language.
Yes, it is. What you describe is called Just-In-Time (JIT) compilation.
> Try to see the difference, if you can.
There is no difference at all, Often Wrong. One can even compile the same
source code into a file in bytecode format, and have the same JavaScript VM
execute that (as it is possible on NES-compatible servers).
> P.S. JScript.NET _is_ a compiled language.
As are JavaScript and JScript. As hard as it may be for you to understand,
compilation does not require a file on the filesystem as its result.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Matt Kruse
> On Apr 22, 10:09 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
> > Bytecode is platform-independent, of course, because a Virtual Machine
> > interprets it. As I have said, in that sense at least JavaScript[tm],
> > and as it turns out JScript also, are compiled languages.
> source code format. The engine naturally compiles it to be able to use
> so the engine works with compiled code - but Javascript is not a
> compiled language.
I hate to agree with VK, but I do.
The terms "compiled" and "interpreted" to refer to programming
languages are both vague and don't have exact meanings to begin with.
They are just labels.
Javascript is interpreted rather than compiled because the raw source
code is delivered to the end user. Of course it is turned into a
machine-readable form before execution - all languages are. Else the
term "interpreted language" would be meaningless.
Javascript is not pre-compiled into byte code which is then delivered
to the client's VM to execute (typically). Is there a standard
javascript bytecode definition that all javascript VM's will execute
identically? In contrast, a language like Java is considered to be a
"compiled" language because you can deliver the pre-compiled .class
files, even though they still require a VM to execute, but compiled
code is not the original source. The line there is even blurry because
you _can_ deliver the source and have it compiled "on the fly".
In the end, the discussion of the labels "compiled" and "interpreted"
is pointless because the reality of how it works is known. Especially
when the terms do not have "scientific" meanings and are open to
interpretation.
Matt Kruse
Thomas 'PointedEars' Lahn
> On Apr 22, 3:34 pm, VK <schools_r...@yahoo.com> wrote:
>> On Apr 22, 10:09 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>> wrote:
>>> Bytecode is platform-independent, of course, because a Virtual
>>> Machine interprets it. As I have said, in that sense at least
>>> JavaScript[tm], and as it turns out JScript also, are compiled
>>> languages.
>> Javascript is being stored and delivered to the engine in the raw text
>> source code format. The engine naturally compiles it to be able to use
>> so the engine works with compiled code - but Javascript is not a
>> compiled language.
>
> I hate to agree with VK, but I do.
Your loss.
> Javascript is not pre-compiled into byte code which is then delivered to
> the client's VM to execute (typically).
Typically (JavaScript[tm] and JScript would cover, say, 95% of the market of
ECMAScript-compliant script engines), it is. You appear to have overlooked
the quotations by their inventors.
> Is there a standard javascript bytecode definition that all javascript
> VM's will execute identically?
There isn't even *a* "javascript VM" to begin with.
All JavaScript[tm] engines will have to use SpiderMonkey or Rhino; for the
former, we now have its inventors assertion that there is a bytecode
specification; for the latter, since it is Java-based, we can assume it has.
All JScript and JScript .NET engines would have to be that which Microsoft
provides with the Microsoft Script Engine (since it's closed source), so no
surprise there either.
> The terms "compiled" and "interpreted" to refer to programming languages
> are both vague and don't have exact meanings to begin with. They are just
> labels.
This is simply wrong. RTFM.
> [...] In the end, the discussion of the labels "compiled" and
> "interpreted" is pointless because the reality of how it works is known.
Parse error.
> Especially when the terms do not have "scientific" meanings and are open
> to interpretation.
No, see above. But what matters here (if it matters at all; to remind you,
the cause of this subthread was a website that compared Prototype.js to Java
and jQuery to Ruby) is that JavaScript and JScript code is compiled *first*.
This does not apply to all languages that are finally interpreted.
What the both of you seem to overlook is that compilation and interpretation
can complement each other.
Richard Cornford
> On Apr 19, 9:02 am, Richard Cornford wrote:
>> One of the arguments paraded in favour of these libraries is
>> that they are examined, worked on and used by very large
>> numbers of people, and so they should be of reasonably high
>> quality because with many eyes looking at the code obvious
>> mistakes should not go unnoticed. My experience of looking
>> at code from the various 'popular' libraries suggests that
>> this is a fallacy, because (with the exception of YUI (for
>> obvious reasons))
>
> Not obvious.
>
> There's plenty of bugs YUI.
Who is talking about bugs? Take this code from the dojo library:-
| if(
| elem == null ||
| ((elem == undefined)&&(typeof elem == "undefined"))
| ){
| dojo.raise("No element given to dojo.dom.setAttributeNS");
| }
The rules for javascirpt dictate then whenever the -
(elem == undefined) - expression is evaluated (that is, whenever
- elem == null - is false) the result of the expression must be
false, and so the - (typeof elem == "undefined") - expression just
cannot ever be evaluated. The bottom line is that if the author of
that code had understood javascript when writing it the whole thing
would have been:-
if(elem == null){
dojo.raise("No element given to dojo.dom.setAttributeNS");
}
- or possibly:-
if(elem){
dojo.raise("No element given to dojo.dom.setAttributeNS");
}
- as there should be no issues following from pushing other
primitive values that have falseness through the exception
throwing path as well null and undefined.
The first is not a bug; it does exactly what it was written to, and
does it reliably and consistently. But it is a stupid mistake on the
part of its 'programmer', and survived in the dojo source for long
enough to be observed because nobody involved with dojo knew enough
actual javascript to see that it was a stupid mistake and correct it.
YUI may contain bugs but it does not contain this type of stupid
mistake because at least one person (and it only takes one) knows
javascript well enough to be able to see this type of thing and
stop it (presumably at source by ensuring any potential
transgressors become better informed bout the language they are
using).
Now JQuery contains the infamous - ( typeof array != "array" )-
stupid mistake, and Prototype.js (at least version 1.6 (which is
not that long ago)) contained the attempt to conditionally employ
function declarations that only worked by coincidence. Neither
of those are bugs as such (they don't stop the respective code
from 'working' (at least to the limited degree to which it is
designed to 'work')), but they are precisely the type of stupid
mistake that follows from code authors having a minimal
understanding of the language they are using. And where those
authors are part of a collective they don't speak for the
knowledge of the specific author responsible but instead
indicate the level of understanding of the _most_
knowledgeable person involved.
<snip>
> A fix for the bug that was demonstrated seems to be by
> simply putting the & last.
>
> String.prototype.unescapeHTML = function() {
> return this.replace(/</g,'<')
> .replace(/>/g,'>')
> .replace(/&/g,'&');
> };
>
> That would need to be tested out though.
No it does not need to be test, it is correct. The general
rule is that the character significant in escaping needs to
be processed first when escaping and last when unescaping.
> Right?
Absolutely. It is a simple bug, and a mistake that in my
experience is made by nearly every programmer who comes to
the issues of encoding/escaping for the web for the first
time (pretty much no matter what their previous level of
experience in other areas). It is something that I have
learnt to double check, habitually, and that is the reason
that I spotted it so quickly.
Richard.
Richard Cornford
>On Apr 19, 3:06 pm, Richard Cornford wrote:
>> Interestingly I observed Matt Kruse (who is the nearest
>> thing to a supporter JQuery has among the regular contributors
>> to this group, and someone who can easily outgun anyone
>> directly involved in JQuery development when it comes to
>> javascript)
>
> Wow, given your view of the jQuery dev team, I'm not sure if
> that's even close to a compliment ;)
Well, you know that I like to call things the way that I see them ;-)
They need you a lot more than you need them.
>> directly asked however was responsible for the -
>> if ( typeof array != "array" ) - code to own up to it in a
>> post on the JQuery development group. However, when I checked
>> back a week later to see if anyone had the intellectual
>> integrity to own up to their mistake I found that Matt's
>> post had been deleted from the group.
>
> If you're referring to this point:
> http://groups.google.com/group/jquery-dev/msg/54b54712bd48ec83
> then I can still find it.
<snip>
That is odd. I can see your post from my computer at home but still not
from work. I cannot believe that our firewall is capable of being
sufficiently subtle as to be censoring a single post in a thread (and
certainly not without messing the rest of the page up in the process).
It does have some very silly aspects to its configuration, like we
cannot view the MSDN page on the - responseXML - property of HTTP XML
request objects because of its URL contains the character sequence made
from the last two letters of "response" and the first letter of "XML",
but that sort of thing should not come into this case.
Richard.
Richard Cornford
> On Apr 19, 11:07 pm, Richard Cornford wrote:
>> Who is going to be deciding what 'constructive' means in
>> this context?
>
> Each individual on his own.
Maybe, but there are circumstances were the best advice possible is to
delete something and start again from scratch, but most individuals who
hear that advice don't regard it is constructive when they do.
> Or, in other words: say what you want to say, and I'll
> brush off anything I think is unwarranted.
Presumably you mean you will brush off anything that you regard as
unwarranted?
> I'm not
> setting conditions for prior restraint here.
Requiring what you get to be "constructive" is not a condition?
>> You mean that if someone is in a 'minority' then they must
>> be wrong? That is hardly an attitude that would allow
>> progress through the adoption of new ideas.
>
> I never said anything of the sort. I said the minority need
> to do more _persuading_.
OK. Why, what is in it for them?
> You stated that these libraries were junk
I very much doubt that I did.
> as though it were common knowledge.
If I had it would not be because it was common knowledge, but rather
because it was the case.
> Clearly it isn't common knowledge.
There are lots of things that are true but are not common knowledge. And
that is even if you are not taking 'common knowledge' as referring to
what is commonly know by ordinary people (ordinarily people mostly being
people who have no idea what javascript is in the first place, and
little interest in knowing).
>> You have not demonstrated that these are questions of taste.
>> The last time we discussed the prototype.js code here in
>> detail (which was version 1.6, in November last year) it
>> demonstrated evidence of or its authors (collectively, as
>> nobody had corrected the code) not understanding how the
>> code they were writing was going to behave. Seeing that
>> brings everything into question, form the original design
>> concepts to every detail of its implementation. And those
>> are not then questions of taste but the inevitable
>> consequence of evident ignorance among its developers.
>
> I hold that any technology decision is a question of taste.
Decisions suggest an informed process of deciding. Otherwise we may be
dealing with no more than the accumulated outcome of sequences of random
influences, misconceptions and learnt incantations. If someone writes:-
<script type="javascript">
var url = " ... ";
...
document.write('<scr'+'ipt type="javascript"
src="'+url+'"></scr'+'ipt>');
</script>
- there are things about that that are not a question of taste at all.
That the mark-up is invalid is an objective fact. That there are two
unnecessary concatenation operations is a fact, and that the apparent
justification for those additional concatenation operations has missed
the point is also a fact.
Some decisions to do things, or not to do things are not a question of
taste, but rather the consequences of understanding.
> There is no objective "better" in the sense of Ruby vs.
> Python, or vi vs. emacs;
Maybe, but there is an objective "better" in the sense of using:-
if(elem == null){
dojo.raise("No element given to dojo.dom.setAttributeNS");
}
- in place of:-
if(
elem == null ||
((elem == undefined)&&(typeof elem == "undefined"))
){
dojo.raise("No element given to dojo.dom.setAttributeNS");
}
- because the latter is just silly in comparison to the former (as they
both have precisely the same outcome).
> there is only the subjective "better" - whichever best
> serves the user's own needs.
There seems to be an unfortunate tendency among web developers to lose
site of who the "user" actually is. The user (for web developers) is the
poor sod looking at an alarming little grey box with yellow 'warning'
triangle just above their web browser's window that says "Your browser
does not support AJAX" and wondering what the hell they are expected to
do about it (get it tickets for the next match or something?).
> Naturally, this does _not_ mean that everything is relative,
> or that it's not worth having passionate arguments thereabout.
> I implied as much in my music analogy: friends argue among
> themselves over which band is "better," but they all realize
> that taste is the ultimate arbiter. These arguments become
> tiresome only when people dig trenches and start speaking
> in absolutes.
>
>> How do you know that? It seems likely to me that Thomas was
>> using his memory of the many (more or less detailed)
>> discussions of Prototype.js code that have happened here
>> over the past few years to inform a general assessment
>> of the code.
>
> And I submit that is a matter of taste.
Thomas's memory is a matter of taste?
> Bugs are bugs,
Not really. There are bugs and there are bugs. A typo in the middle of a
large block of code is something that can happen to anyone, and it could
also easily be missed by others reviewing that code. A glaring error in
something that experience would teach you to always double check and
also should be exposed in any reasonable testing is something else
entirely.
> of course, and we welcome bug reports. But you've gone
> further than that; you've inferred from "evidence" that
> code in Prototype does not do what its author means for
> it to do.
No, I said that the evidence was that Prototype.js was (at least in
November last year) only doing what was (apparently) expected by
coincidence; that it had not actually been programmed to do what it was
doing. I also implied that were that evidence existed it was reasonable
to question the understanding of javascript that informed all of the
design decisions that occurred prior to that code being written; such as
the underlying design approach and the resulting API.
(I have also pointed out that Prototype.js is incredibly slow at doing
pretty much anything complex)
>>> I think it's far more constructive to say "Most of us
>>> are not library fans, so you're unlikely to find useful
>>> answers here,"
>>
>> That would not be a true statement (at least the second
>> part of it, and the first part if you take the word
>> 'library' in its most general sense).
>
> Then write your own words.
I did.
> That way they'll be _from the heart_.
No they would not. They would be from the head.
> You know the point I'm trying to make.
Not really.
<snip>
>> ... . There is a lot to be said for the uncensored
>> exchange of ideas in public.
>
> The word "censorship" doesn't come within miles of this
> thread.
Well this is Usenet so there is no censorship.
> I do not own a telecommunications company; I don't have
> the means or authority to "censor" anyone.
You would not have the means to censor Usenet even if you did own a
telecommunications company.
> I can only imagine the OP was interested in the free
> exchange of ideas when he asked you why you thought
> jQuery and Prototype were junk.
He (do you have any evidence that he is a 'he'?) did not ask me
anything.
<snip>
>> ... . From the point of view of someone wanting a better
>> understanding of javascript or browser scripting who just
>> happens to be using some 'popular' library then they really
>> would get the best answers to their questions here, if they
>> could present their questions in isolation (from all of the
>> unrelated and irrelevant stuff that those libraries contain).
>
> That last sentence is the answer to such a FAQ.
It is already in the FAQ in as many words.
> Even a link to that question and answer would be more
> helpful than what has happened in this thread.
Not really. The OP is not asking for specific information on javascript,
and there is no code to post in relation to the question. The question
asked was along the lines of "having learnt something about Prototype.js
should I then spend some time learning something about JQuery". To
which the direct answer appears to have been "no" (if a little more
strongly/colourfully expressed). My answer, in as far as I answered the
question at all, was 'learn javascript and browser scripting first and
then you can make up your own mind'.
>>> A large portion of those who post on this newsgroup aren't
>>> participants or even lurkers;
>>
>> If they post questions then they are participants.
>
> I mean that they weren't participants before their first post.
And they weren't human before they were conceived.
> Many posters, I would venture, only come here when they
> need help, and therefore aren't already familiar with the
> quirks of the community.
There is no need to "venture" that, it is self-evidently true.
>>> they come by only when they have problems. They can't
>>> be expected to catch up on the backstory.
>>
>> They can. Expecting someone to do a few web searches before they ask
>> to
>> be spoon fed is not too unreasonable.
>
> Please search this newsgroup for the terms "Prototype"
What are you expecting? You give a library the same name as a
significant aspect of the language it written in and then cannot find
specific references to it in the archives of a newsgroup dedicated to
that language. It was a predictably bad choice of name.
> and/or "jQuery" and see how quickly you find a well-summarized
> critique of either library.
Who said finding that sort of thing out was going to be quick? I bet the
search would still turn out to be informative even if it could not be
instantaneous.
<snip>
>> but redefine them for WebKit and IE because the String#replace
>> approach is much, much faster in these two browsers (but much,
>> much slower in FF and Opera).
>
> Can you post a test-case that demonstrates that assertion?
> Historically IE has been renowned for its lousy performance
> with string manipulation, while Mozilla outperformed everyone
> else in that area.
>
> I don't have a test-case. The change was made one year ago by
> Thomas Fuchs [1]. You're welcome to ask him, though I suspect
> he'll punch me in the sternum for having dragged him into this.
He won't have to. I will just dismiss this as yet another
unsubstantiated rumour.
<snip>
>>> To be sure, there are other UA sniffs in Prototype that
>>> hard-liners would decry as unnecessary.
>>
>> It is not 'unnecessary' that is the questionable aspect of
>> browser sniffing, but rather that it is technically baseless
>> and demonstrably ineffective.
>
> You haven't demonstrated that anything is baseless
How would you expect me to demonstrate the lack of any technical
foundation for UA string based browser sniffing? I can hardly point to
something that doesn't exist and say "there is the absence of any
technical foundation for all to see". Of course if there was any
technical foundation then that could be pointed at quite easily, but as
the navigator.userAgent string is a reflection of the HTTP User Agent
header then any such direction must lead to the definition of the header
in the HTTP specification, and that definition pretty much says that the
User Agent header is an arbitrary sequined of zero or more characters
that is not even required to be consistent from one request to the next
(i.e. that it is not specified as being a source of information at all).
> or ineffective;
Does that need to be demonstrated (again)? It is known that web browsers
use User Agent headers that are indistinguishable form the default UA
header of IE, so how could it be effective to discriminate between
browsers using the UA string whenever two different browsers use UA
headers that are indistinguishable?
> you've only revealed a different set of priorities.
> You'd rather have 100% guaranteed behavior
I would certainly rather have consistent and predictable behaviour
before worrying about performance.
> even if it meant a wildly-varying performance
> graph across browsers.
Where is the evidence for "wildly-varying"? I don't think
escaping/unescaping methods are going to be used frequently enough for
their specific performance to mattered that much at all. If you used
them internally, or they were fundamental to using the library in the
first place then their performance would be much more significant.
> I'd rather have the reverse.
So you would not be certain what the code was going to do, but you would
know that whatever it did it would take about the same amount of time to
do it wherever it was running? I certainly do not have a taste for that
design philosophy.
>> But I suppose that you would not agree that being able to
>> find an obvious rookie mistake in less then three seconds
>> of looking (at a library that is already a good few years
>> old) tends to support the "junk" assessment.
>
> The check-in is only one year old. It is Thomas's bug, but he
> is no rookie,
Hansom is as hansom does. But that was not really my point. One of the
things that gets proposed as a justification for libraries of this sort
(a reason for their not being junk by virtue of what they are) is that
with many individuals contributing there are plenty of eyes looking at
the code to be able to find these sorts of things and fix them up front.
But if it takes me three seconds to find what nobody else had noticed
then it must be the case that there is nobody involved looking with my
eyes.
> so I can only surmise that we all make silly mistakes
> sometimes. Bad luck for him that he managed to stumble
> upon your Shibboleth Bug(TM).
Bad luck for everyone else who manage to let it pass unnoticed.
>>> A bug was filed on this not too long ago; I believe a
>>> fix has been checked into trunk and will be in the
>>> next release.
>
>> Well, it is a pretty simple fix, and I notice that the subject
>> of my last substantial criticism of the prototype's code has
>> also been removed.
>
> We listen to criticism, we read bug reports, and we constantly
> search for ways to improve the feedback loop.
That all sounds very 'marketing-speak'.
> So does John Resig, by the way, so I'd suggest you file a bug
> on jQuery's Trac about the "makeArray" mistake.
Why? Polishing the handrails on the Titanic may have made it more
appealing to look at but didn't change the rate at which it sank after
the design flaw coincided with the iceberg.
Richard.
Richard Cornford
> On Apr 20, 5:46 pm, Richard Cornford wrote:
<snip>
>> ... none of the existing popular libraries perform anywhere
>> near fast enough for the web applications I work on, and
>> they never could.
>
> Is it possible to see the above mentioned web applications?
An invisible web application would not be very easy to use (or sell).
But you mean is it possible for you to see them. If you can convince our
marketing department that you are a potential customer they will happily
demonstrate it to you (in your own offices, anywhere on the planet, and
at your convenience). Their question will be "how much property do you
own/manage?", but if the answers is much less than 1000 building they
are probably not going to be interested.
Richard.
Lasse Reichstein Nielsen
> Matt Kruse wrote:
>> The terms "compiled" and "interpreted" to refer to programming languages
>> are both vague and don't have exact meanings to begin with. They are just
>> labels.
>
> This is simply wrong.
No, it's not.
> RTFM.
Link?
Compiling and interpreting are processes. Applying the names to
langauges as a whole suggests (but is not formally defined) that the
language is inherently using that process. That is not how most
langauges are specified. Instead they are specified at the semantic
level, allowing both interpretation and compilation.
If instead we look at the, formal, definitions of an Interpreter and a
Compiler, then it becomes clearer how to, at least, distinguish the
processes.
An interpreter is defined by *two* things: The interpreted (source)
language, and the implementation language.
In order to use it, you run the implementation language and give
the source language program as input. The application of the
interpreter to the program, Interpreter(source), must have the same
semantics in the implementation language, as the souce program has
in the interpreted language.
A compiler is defined by *three* things: The source language, the
target language, and the implementation language.
You run the implementation language with the source program as input
and receive a program in the target language as output.
The target progrem must have the same semantics in the target language
as the source program has in the source language.
The typical meaning of a "compiled language" is one where the source
program is compiled to another form once and then that form is stored
and run several times. I.e., where the process of compilation is
separate from the process of interpreting the compiled form.
>> Especially when the terms do not have "scientific" meanings and are open
>> to interpretation.
>
> No, see above. But what matters here (if it matters at all; to remind you,
> the cause of this subthread was a website that compared Prototype.js to Java
> and jQuery to Ruby) is that JavaScript and JScript code is compiled *first*.
The combination of first compiling and then executing implements an
interpreter. Nothing prevents an interpreter from using a compiler as
a component, but its behavior is still clearly that of an interpreter:
it executes the program.
That means that Javascript used on the web is always interpreted.
> This does not apply to all languages that are finally interpreted.
>
> What the both of you seem to overlook is that compilation and interpretation
> can complement each other.
Absolutely. But if "compiled language" and "interpreted language" is to
have any meaning (which I doubt it has), the most significant process
should be the deciding factor, and Javascript is typically interpreted,
whether that interpreter contains an internal compiler or not.
I know there are exceptions where Javasscript is compiled offline and
transmitted in compiled form, but that only strengthens the point that
"compiled language" and "interpreted language" are meaningless.
Thadeu de Paula
wrote:
> I am learning more and more Prototype and Script.aculo.us and got the
> Bungee book... and wonder if I should get some books on jQuery (jQuery
> in Action, and Learning jQuery) and start learning about it too?
>
> Once I saw a website comparing Prototype to Java and jQuery to Ruby...
> but now that I read more and more about Prototype, it is said that
> Prototype actually came from Ruby on Rails development and the creator
> of Prototype created it with making Prototype work like Ruby in mind.
> Is jQuery also like Ruby? Thanks so much for your help.
They are not bad... if you don't want to use javascript. The better is
you learn JS. Then, seeing it's code you'll know what it do.
But imagine...
Using Prototype, jQuery etc.. you'll need to load these scripts in all
your pages... using all functions or not. They create variables to
store long built-in JS properties. This is unnecessary.
The better is you code your object and functions and load only
necessary
to do especific things. And... about code... if you use many
document.objasdjhk()
and wanto to keep the code smaller... compress it with an javascript
compressor and keep the original code to edition.
Prototype, jQuery are "good" works from people that knows JS. But it
can
not be the best way of implement JS in your pages.
beegee
<snip>
> The combination of first compiling and then executing implements an
> interpreter. Nothing prevents an interpreter from using a compiler as
> a component, but its behavior is still clearly that of an interpreter:
> it executes the program.
>
Yes, that is a very clear definition. Now, what is the difference
between an interpreter and a virtual machine? PointedEars suggests
they are the same thing. Certainly both execute a program and both
use a compiler as a component.
Instinctively, I know there is a difference between languages such as
Javascript, Ruby on one hand and Java,.NET C# on the other. There is
a trade off of speed for expression that I at first attributed to
compilation vs. interpretation. Recently, I've noticed that C# has
added lambdas and a variant (typeless) type to the latest version.
The syntax is kind of a nightmare compared to Javascript but it means
that VM is doing the same kind of "interpretation" that the Javascript
interpreter is doing. So maybe the difference between these languages
is that one type is oriented toward compilation and the other is
oriented toward interpretation even though they have evolved towards
each other.
Bob
Thomas 'PointedEars' Lahn
> Now, what is the difference between an interpreter and a virtual machine?
> PointedEars suggests they are the same thing. Certainly both execute a
> program and both use a compiler as a component.
Not necessarily.
> Instinctively, I know there is a difference between languages such as
> Javascript, Ruby on one hand and Java,.NET C# on the other.
So at least partially you would be let down by your instincts. At least as
for JavaScript, JScript, JScript .NET, and Java, there is no difference
regarding this as should have been clear to you by now.
Joost Diepenmaat
> Recently, I've noticed that C# has
> added lambdas and a variant (typeless) type to the latest version.
> The syntax is kind of a nightmare compared to Javascript but it means
> that VM is doing the same kind of "interpretation" that the Javascript
> interpreter is doing. So maybe the difference between these languages
> is that one type is oriented toward compilation and the other is
> oriented toward interpretation even though they have evolved towards
> each other.
This is nothing new. Take a look at Common Lisp for a language that has
both extreme expressiveness and compilers that can produce very fast
code. Anyway the border between interpreted and compiled implementations
is very fuzzy (unless you just mean that you can transform the source
code to some pre-processed byte stream or stand-alone executable, which
is really quite easy and doesn't really mean much. Many languages that are
typically viewed as interpreted (perl, for instance) can do that.
This whole discussion is pretty meaningless.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
dhtml
wrote:
I really didn't want to be goaded into postup a dumb and dumber
competition with other people's code, but you've left me with not very
good choices.
YUI has some pretty bad/obvious bugs in crucial places. augmentObject,
hasOwnProperty. Dom.contains:-
hasOwnProperty: function(o, prop) {
if (Object.prototype.hasOwnProperty) {
return o.hasOwnProperty(prop);
}
return !YAHOO.lang.isUndefined(o[prop]) &&
o.constructor.prototype[prop] !== o[prop];
},
- Which will throw errors in IE when - o - is a host object and
return wrong results in Opera when - o - is window. augmentObject:-
augmentObject: function(r, s) {
if (!s||!r) {
throw new Error("Absorb failed, verify dependencies.");
}
var a=arguments, i, p, override=a[2];
if (override && override!==true) { // only absorb the
specified properties
for (i=2; i<a.length; i=i+1) {
r[a[i]] = s[a[i]];
}
} else { // take everything, overwriting only if the third
parameter is true
for (p in s) {
if (override || !r[p]) {
r[p] = s[p];
}
}
YAHOO.lang._IEEnumFix(r, s);
}
},
It is questionable strategy to do object augmentation on the prototype
chain of the supplier. It would be better to use hasOwnProperty to
filter the stuff in the supplier's prototype chain out. Next, if the
receiver has a property p with a false-ish value, then the ovveride
flag is irrelevant.
Dojo calls object augmentation "extend" which to me seems to be
misleading.
isAncestor: function(haystack, needle) {
haystack = Y.Dom.get(haystack);
needle = Y.Dom.get(needle);
if (!haystack || !needle) {
return false;
}
if (haystack.contains && needle.nodeType && !isSafari)
{ // safari contains is broken
YAHOO.log('isAncestor returning ' +
haystack.contains(needle), 'info', 'Dom');
return haystack.contains(needle);
}
else if ( haystack.compareDocumentPosition &&
needle.nodeType ) {
YAHOO.log('isAncestor returning ' + !!
(haystack.compareDocumentPosition(needle) & 16), 'info', 'Dom');
return !!(haystack.compareDocumentPosition(needle) &
16);
} else if (needle.nodeType) {
// fallback to crawling up (safari)
return !!this.getAncestorBy(needle, function(el) {
return el == haystack;
});
}
YAHOO.log('isAncestor failed; most likely needle is not an
HTMLElement', 'error', 'Dom');
return false;
}
This would return inconsistent results, depending on the browser.
For example:
YAHOO.util.Dom.isAncestor(document.body, document.body);
Though the last is not as obvious a mistake as the others.
There are considerably questionable practices in the Event library.
The connection manager is horribly designed. The fact that it attempts
to do form serialization within iteself, is just a horrible decision.
If the author had been forced to write a test for that, he'd probably
have moved that form serialization code somewhere else, to make it
easier to test (easier coverage verification).
[snip]
> And where those
> authors are part of a collective they don't speak for the
> knowledge of the specific author responsible but instead
> indicate the level of understanding of the _most_
> knowledgeable person involved.
>
This can lead to blocking code reviews and scape goating. With a test
driven approach, the only thing to blame is the process, and that's
fixable (besides the fact that the test never has any hard feelings).
Without tests, you get things like blood commits and code freezes.
Some libraries actually do code freezes. And they have at least one
expert. And they have bugs. Dumb ones.
> <snip>
>
> > A fix for the bug that was demonstrated seems to be by
> > simply putting the & last.
>
> > String.prototype.unescapeHTML = function() {
> > return this.replace(/</g,'<')
> > .replace(/>/g,'>')
> > .replace(/&/g,'&');
> > };
>
> > That would need to be tested out though.
>
> No it does not need to be test, it is correct. The general
> rule is that the character significant in escaping needs to
> be processed first when escaping and last when unescaping.
>
It addresses the problem that was demonstrated in your example. It
does not, however, take into consideration the possibility that - this
- could contain * any * other entities.
If the need to handle - " - or & (which is also '&') got
added in later, they'd need to be reviewed by the one, sole expert, to
make sure the person who wrote the amending code didn't make a rookie
mistake. A test could clearly prove it worked.
var s = """.replace(/"/g, '"');
So the fix addresses only one concern.
another consideration is that String.prototype.escapeHTML should be
stable, but if there's a bug, and dependencies on that bug, then the
fixing of the bug becomes complicated. In may very well be the case
that some novice programmer used escapeHTML, found that it didn't work
right, made some adjustments in his implementation to compensate for
that bug. In essence, his implementation is now depending on that bug.
This is where I see adding things to built-in prototypes to be risky.
If the programmer had made a method, then that method could always be
deprecated in a future release, if found to be problematic.
So, to sum it up, my recommentations:
1) write a test
2) don't put the methods on String.prototype because they might change
later.
> > Right?
>
> Absolutely. It is a simple bug, and a mistake that in my
> experience is made by nearly every programmer who comes to
> the issues of encoding/escaping for the web for the first
> time (pretty much no matter what their previous level of
> experience in other areas). It is something that I have
> learnt to double check, habitually, and that is the reason
> that I spotted it so quickly.
>
That was my first time writing an unescape function in Javascript. I
think I might have written one in Java several years ago in a response
filter exercise, though.
If I had to write something more comprehensive to account for more
entities, I'd probably consider looking into inverting control to the
browser's parser using a combination of newDiv.innerHTML and
newDiv.textContent|innerText
document.body.textContent = "&";
document.body.innerHTML; // &
document.body.innerHTML = """
document.body.textContent; // "
Obviously not using document.body, but a newly created node. I would
probably write some tests for that, including the cases you posted,
make sure they all fail, then write out some code (the code could be
changed in the future, since there are tests).
Garrett
> Richard.
Andrew Dupont
wrote:
> Andrew Dupont wrote:
> > On Apr 19, 11:07 pm, Richard Cornford wrote:
> >> Who is going to be deciding what 'constructive' means in
> >> this context?
>
> > Each individual on his own.
>
> Maybe, but there are circumstances were the best advice possible is to
> delete something and start again from scratch, but most individuals who
> hear that advice don't regard it is constructive when they do.
>
> > Or, in other words: say what you want to say, and I'll
> > brush off anything I think is unwarranted.
>
> Presumably you mean you will brush off anything that you regard as
> unwarranted?
How is that different?
> > I'm not
> > setting conditions for prior restraint here.
>
> Requiring what you get to be "constructive" is not a condition?
You're hyper-parsing my statements. I think the response the OP got
_isn't constructive_ clearly you disagree. I think some of the
criticism of Prototype that occurs in this newsgroup _isn't
constructive_, but some _is_. I am saying that I will disregard things
that I don't feel are constructive. Therefore there is no
"requirement" of any sort. Jesus.
>
> >> You mean that if someone is in a 'minority' then they must
> >> be wrong? That is hardly an attitude that would allow
> >> progress through the adoption of new ideas.
>
> > I never said anything of the sort. I said the minority need
> > to do more _persuading_.
>
> OK. Why, what is in it for them?
Nothing. Go eat a taco if you like.
>
> > You stated that these libraries were junk
>
> I very much doubt that I did.
Somewhere along the way I got you mixed up with Thomas. For that I
apologize.
> > Clearly it isn't common knowledge.
>
> There are lots of things that are true but are not common knowledge.
I'm not arguing whether it's true or not. If I say "Martin Scorsese
can't direct for shit," I expect people around me to look at me funny,
because whether my statement is true or not it goes against consensus.
Therefore I might feel a burden to _elaborate_.
> Maybe, but there is an objective "better" in the sense of using:-
>
> if(elem == null){
> dojo.raise("No element given to dojo.dom.setAttributeNS");
>
> }
>
> - in place of:-
>
> if(
> elem == null ||
> ((elem == undefined)&&(typeof elem == "undefined"))
> ){
> dojo.raise("No element given to dojo.dom.setAttributeNS");
>
> }
And you seem to say that a small handful of silly choices in a
framework mean the entire thing is worthless.
> >> How do you know that? It seems likely to me that Thomas was
> >> using his memory of the many (more or less detailed)
> >> discussions of Prototype.js code that have happened here
> >> over the past few years to inform a general assessment
> >> of the code.
>
> > And I submit that is a matter of taste.
>
> Thomas's memory is a matter of taste?
No, his assessment is a matter of taste. The part that connects his
memory and his opinion.
> Not really. There are bugs and there are bugs. A typo in the middle of a
> large block of code is something that can happen to anyone, and it could
> also easily be missed by others reviewing that code. A glaring error in
> something that experience would teach you to always double check and
> also should be exposed in any reasonable testing is something else
> entirely.
We disagree on the degree to which this is important. I think we've
gone as far as we can on this point.
>
> > of course, and we welcome bug reports. But you've gone
> > further than that; you've inferred from "evidence" that
> > code in Prototype does not do what its author means for
> > it to do.
>
> No, I said that the evidence was that Prototype.js was (at least in
> November last year) only doing what was (apparently) expected by
> coincidence; that it had not actually been programmed to do what it was
> doing. I also implied that were that evidence existed it was reasonable
> to question the understanding of javascript that informed all of the
> design decisions that occurred prior to that code being written; such as
> the underlying design approach and the resulting API.
> (I have also pointed out that Prototype.js is incredibly slow at doing
> pretty much anything complex)
That's a very vague statement. A few examples would be greatly
appreciated. The words "slow," "anything," and "complex" are relative
to the individual, and obviously must be taken into account when
making a technology decision. jQuery's central API focus — fetching
nodes by CSS selector — means that a line of jQuery code is often much
slower than the equivalent, non-framework-aided code. Many people use
it anyway because they deem it to be worth the trade-off.
>
> >>> I think it's far more constructive to say "Most of us
> >>> are not library fans, so you're unlikely to find useful
> >>> answers here,"
>
> >> That would not be a true statement (at least the second
> >> part of it, and the first part if you take the word
> >> 'library' in its most general sense).
>
> > Then write your own words.
>
> I did.
>
> > That way they'll be _from the heart_.
>
> No they would not. They would be from the head.
>
> > You know the point I'm trying to make.
>
> Not really.
Apparently I need to stop using sarcasm. I also need to stop speaking
abstractly, aside from basic declaratives (e.g., "Your tone is too
harsh."). You are reading the most literal of meanings into every
single word I write.
> >> ... . There is a lot to be said for the uncensored
> >> exchange of ideas in public.
>
> > The word "censorship" doesn't come within miles of this
> > thread.
>
> Well this is Usenet so there is no censorship.
>
> > I do not own a telecommunications company; I don't have
> > the means or authority to "censor" anyone.
>
> You would not have the means to censor Usenet even if you did own a
> telecommunications company.
Case in point. I don't know why you think I was trying to censor
conversation in the first place. My point is that I can't (and don't
want to) censor anything.
> > I mean that they weren't participants before their first post.
>
> And they weren't human before they were conceived.
Needlessly argumentative and willfully dense to the point I'm making.
> > Many posters, I would venture, only come here when they
> > need help, and therefore aren't already familiar with the
> > quirks of the community.
>
> There is no need to "venture" that, it is self-evidently true.
>
> >>> they come by only when they have problems. They can't
> >>> be expected to catch up on the backstory.
>
> >> They can. Expecting someone to do a few web searches before they ask
> >> to
> >> be spoon fed is not too unreasonable.
>
> > Please search this newsgroup for the terms "Prototype"
>
> What are you expecting? You give a library the same name as a
> significant aspect of the language it written in and then cannot find
> specific references to it in the archives of a newsgroup dedicated to
> that language. It was a predictably bad choice of name.
Again, argumentative. The fact it's a bad name for a library (which I
agree with) is unrelated to the point I am making.
>
> > and/or "jQuery" and see how quickly you find a well-summarized
> > critique of either library.
>
> Who said finding that sort of thing out was going to be quick? I bet the
> search would still turn out to be informative even if it could not be
> instantaneous.
This is like saying I ought to read the entirety of Donald Knuth's
published works before I write a simple algorithm. You may be right in
your "bet," but that's not how a user in need of help is going to
_behave_, so what's the user of pretending otherwise?
> >>> To be sure, there are other UA sniffs in Prototype that
> >>> hard-liners would decry as unnecessary.
>
> >> It is not 'unnecessary' that is the questionable aspect of
> >> browser sniffing, but rather that it is technically baseless
> >> and demonstrably ineffective.
>
> > You haven't demonstrated that anything is baseless
>
> How would you expect me to demonstrate the lack of any technical
> foundation for UA string based browser sniffing? I can hardly point to
> something that doesn't exist and say "there is the absence of any
> technical foundation for all to see". Of course if there was any
> technical foundation then that could be pointed at quite easily, but as
> the navigator.userAgent string is a reflection of the HTTP User Agent
> header then any such direction must lead to the definition of the header
> in the HTTP specification, and that definition pretty much says that the
> User Agent header is an arbitrary sequined of zero or more characters
> that is not even required to be consistent from one request to the next
> (i.e. that it is not specified as being a source of information at all).
>
> > or ineffective;
>
> Does that need to be demonstrated (again)? It is known that web browsers
> use User Agent headers that are indistinguishable form the default UA
> header of IE, so how could it be effective to discriminate between
> browsers using the UA string whenever two different browsers use UA
> headers that are indistinguishable?
First of all: we don't sniff the UA string to detect IE. We sniff to
distinguish between other browsers (e.g., between Gecko and WebKit),
but we use a different heuristic for IE.
Second: your gripe seems to be that we use any heuristic at all — that
it's not possible to detect differences in UAs with 100% accuracy.
99.99% accuracy is good enough for me. I'm not insisting that you must
agree; I'm only asking not to be regarded as a savage.
> So you would not be certain what the code was going to do, but you would
> know that whatever it did it would take about the same amount of time to
> do it wherever it was running? I certainly do not have a taste for that
> design philosophy.
No, I would rely on the unit tests to demonstrate a consistent
behavior. It doesn't give me 100% certainty because I can't test every
string on earth. (In this case, obviously, we didn't test enough
strings.)
> >> But I suppose that you would not agree that being able to
> >> find an obvious rookie mistake in less then three seconds
> >> of looking (at a library that is already a good few years
> >> old) tends to support the "junk" assessment.
>
> > The check-in is only one year old. It is Thomas's bug, but he
> > is no rookie,
>
> Hansom is as hansom does. But that was not really my point. One of the
> things that gets proposed as a justification for libraries of this sort
> (a reason for their not being junk by virtue of what they are) is that
> with many individuals contributing there are plenty of eyes looking at
> the code to be able to find these sorts of things and fix them up front.
> But if it takes me three seconds to find what nobody else had noticed
> then it must be the case that there is nobody involved looking with my
> eyes.
Again: someone else did notice it. But it did go unfixed for about a
year, and I find that disappointing and unusual. We agree on the
former but not the latter.
> > We listen to criticism, we read bug reports, and we constantly
> > search for ways to improve the feedback loop.
>
> That all sounds very 'marketing-speak'.
Again, you're being oddly argumentative. I don't care how it sounds to
you.
>
> > So does John Resig, by the way, so I'd suggest you file a bug
> > on jQuery's Trac about the "makeArray" mistake.
>
> Why? Polishing the handrails on the Titanic may have made it more
> appealing to look at but didn't change the rate at which it sank after
> the design flaw coincided with the iceberg.
Are you sure? The bug submission screen has a gigantic text box in
which you can make any sort of condescending judgment you like. How
can you resist?
Cheers,
Andrew
Peter Michaux
[snip]
> People here will keep complaining about the shoddy quality of
> libraries while that quality, slowly, increases.
I keep wondering why the process is so slow. The cores of all the
major libraries like Prototype.js, jQuery, etc are all relatively
small (~a few thousand lines). In a month I'm sure someone could go
through these libraries in great detail and find and fix many
problems.
One reason I can think up is the library granularity, packaging and
API are not of interest to experts who would know how to fix the
internals. That is, even if these libraries were technically perfect
the experts that complain about them still wouldn't use them. I think
this is primarily true for Prototype.js because augmenting objects you
don't own is something almost everyone stops doing very early on. I
don't know how the Prototype.js folks can find this practice
acceptable as it has burned them quite a few times.
> This goes on until
> the time when libraries have won, and anybody not using them is
> putting themselves at a disadvantage.
I think that time has already come. It seems most c.l.j regulars who
complain about the mainstream libraries do maintain their own
libraries in various forms. Some of the various forms have interesting
APIs and priorities that are quite different than popular libraries.
I think the time will come very soon that maintaining one's own
library may not be feasible because the size of the library will be
too big. The boss will want big fancy widgets faster than before
because someone using a library can produce them quickly even though
they may have known bugs or have bloated code with large unused
portions being served to the client.
Peter
VK
> I keep wondering why the process is so slow. The cores of all the
> major libraries like Prototype.js, jQuery, etc are all relatively
> small (~a few thousand lines). In a month I'm sure someone could go
> through these libraries in great detail and find and fix many
> problems.
Easy to say - really hard to implement. It may take a couple of hours
to "streamline" some code upon programmer's idea of the best. But such
freedom of actions is available only for a new player on the market.
For a library long time used in serious commercial solutions the main
priority is not "beauty" or even effectiveness of code, these are all
secondary matters. The main mandatory priority is backward
compatibility - not only with the previous versions of the library
itself, but also with all current solutions using this library.
Sometimes it locks the possibility to update a segment even if its
clearly ineffective or wrong: because some big solutions are using
workarounds dependent on this particular segment structure.
This is the main rule and trend of the commercial programming: long
used software has an established brand and customer base, but unable
to be very flexible due to backward compatibility requirements. A new
player has to fight its way through: but being free of current
commercial obligations it can be much more flexible and dynamic so to
satisfy better new customers. In case of success it gets its own
market share and its own commercial responsibility so loosing the
initial advantage of the flexibility - and the process starts over.
> have bloated code with large unused
> portions being served to the client.
This part of complains oftenly seen at c.l.j. are really strange. OOP
by itself doesn't provide easy mechanics for "per chunk" code usage.
This is the generic trade off of OOP: it has high maintainability but
low modularity. In order to use someMethod from library X it is needed
to include all someMethod dependencies as well: which oftenly mean all
inheritance chain up to Object. With the common namespace protection
pattern where the whole library is one global object one would need to
write an AI enforced compiler to get only the needed parts and to get
them back together properly. And still in the majority of cases it
will result in copying the entire inheritance chain - so nothing but
an error prone loss of time out of such compiler. OOP library usage is
per library, not per method based. I do not understand why the generic
feature of the OOP paradigm is used to criticize Javascript libraries
alone as if it would some exclusive Javascript default. In OOP the
regular solution to the problem is having some commonly agreed core
libraries guaranteed to be presented and then developing own libraries
as extra layer(s) atop of core. Javascript is slowly moving to this
direction. The first necessary step was to let the market to clean up
the initial anarchy of N different libraries on each corner. This step
is pretty much accomplished as of this year, with Prototype being an
industry standard with jQuery second industry standard compliant
library. There are also MooTools and dojo frameforks but they are
operating on a different segment of the market: their purpose is to
move on client as much logic as client can take without freezing its
interface.
RobG
> On Apr 26, 9:42 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > I keep wondering why the process is so slow. The cores of all the
> > major libraries like Prototype.js, jQuery, etc are all relatively
> > small (~a few thousand lines). In a month I'm sure someone could go
> > through these libraries in great detail and find and fix many
> > problems.
>
> Easy to say - really hard to implement. It may take a couple of hours
> to "streamline" some code upon programmer's idea of the best. But such
> freedom of actions is available only for a new player on the market.
> For a library long time used in serious commercial solutions the main
> priority is not "beauty" or even effectiveness of code, these are all
> secondary matters. The main mandatory priority is backward
> compatibility - not only with the previous versions of the library
> itself, but also with all current solutions using this library.
By that criterion, Prototype.js is a poor choice. The assertion
doesn't stack up anyway - a site that has been developed with a
particular version of a library is under no compulsion to change to
newer versions as they become available.
Anyway, I understood Peter's comment to be in regard to fixing bugs
and poor design in the actual code, not to change the API.
> Sometimes it locks the possibility to update a segment even if its
> clearly ineffective or wrong: because some big solutions are using
> workarounds dependent on this particular segment structure.
Anyone who writes code that is dependent on aberrant behaviour
deserves what they get. I see no evidence in Prototype.js that they
refuse to fix bugs because it will cause previous versions to break if
the new version is substituted (noting that there is no compulsion to
use newer versions anyway).
> This is the main rule and trend of the commercial programming: long
> used software has an established brand and customer base, but unable
> to be very flexible due to backward compatibility requirements.
Provide a single example of where the authors of Prototype.js have
refused to fix a bug because it will break backward compatibility.
[...]
> > have bloated code with large unused
> > portions being served to the client.
>
> This part of complains oftenly seen at c.l.j. are really strange. OOP
> by itself doesn't provide easy mechanics for "per chunk" code usage.
Rubbish. The fundamental design of a library can be extremely modular
if that is the designer's choice. It just happens that some popular
libraries are not designed to be modular.
> With the common namespace protection
> pattern where the whole library is one global object one would need to
> write an AI enforced compiler to get only the needed parts and to get
> them back together properly.
Not at all - it has been shown here that using:
var XXLIB = {
fnOne: function(){...},
fnTwo: function(){...},
...
};
provides no more (and possibly less) of a "name space" than the
effectively equivalent:
function XXLIB_fnOne(){...}
function XXLIB_fnTwo(){...}
however the former pattern is used more frequently as it seems more OO
than the latter. Neither pattern forces any kind of internal
dependency. You should try to track down the various ways of creating
an array in Prototype.js.
String.prototype.toArray is the trivial and limited:
toArray: function() {
return this.split('');
},
the $A function uses the bog standard:
function $A(iterable) {
if (!iterable) return [];
if (iterable.toArray) return iterable.toArray();
var length = iterable.length || 0, results = new Array(length);
while (length--) results[length] = iterable[length];
return results;
}
however Enumerable.toArray follows a torturous route through map, Hash
and several other parts of the library. So what does that tell you
about the author's intentions to modularise the code? Clearly it
wasn't a priority (which isn't necessarily a criticism, it's a
statement of fact).
Saying it is impossible to write modular OO code just because a few
popular libraries aren't modular is not a particularly convincing
argument.
> And still in the majority of cases it
> will result in copying the entire inheritance chain - so nothing but
> an error prone loss of time out of such compiler.
There is no reason why a library must be based on an inheritance
chain, nor does that approach necessarily make modularisation more
difficult. Prototype.js takes the approach of extending nearly all
the built-in objects other than Object, however that doesn't
necessarily make one part of the code dependent on another - it is a
consequence of how the library has been written.
> OOP library usage is
> per library, not per method based.
Continually repeating the same statement does not make it so.
Internal dependencies are not necessarily a fundamental feature of OO
programming per se - the reverse *should* be the norm.
> I do not understand why the generic
> feature of the OOP paradigm is used to criticize Javascript libraries
> alone as if it would some exclusive Javascript default.
Because is isn't a fundamental "feature" of OO design.
> In OOP the
> regular solution to the problem is having some commonly agreed core
> libraries guaranteed to be presented and then developing own libraries
> as extra layer(s) atop of core.
The same old assertion.
> Javascript is slowly moving to this
> direction.
It is?
> The first necessary step was to let the market to clean up
> the initial anarchy of N different libraries on each corner. This step
> is pretty much accomplished as of this year, with Prototype being an
> industry standard with jQuery second industry standard compliant
> library.
"Industry standard compliant library". That is there any such thing
as "industry standard" in client-side browser scripting?
--
Rob
VK
> it has been shown here that using:
>
> var XXLIB = {
> fnOne: function(){...},
> fnTwo: function(){...},
> ...
>
> };
>
> provides no more (and possibly less) of a "name space" than the
> effectively equivalent:
>
> function XXLIB_fnOne(){...}
> function XXLIB_fnTwo(){...}
With the latter ("Macromedia notation") even more efficient at least
for JScript where DispIDs are not reusable so any lookup chain
abbreviation brings better performance. Alas the ol'good "Macromedia
notation" is currently a victim of programming fashion. Namely it is
"out of fashion".
> > OOP library usage is
> > per library, not per method based.
>
> Continually repeating the same statement does not make it so.
> Internal dependencies are not necessarily a fundamental feature of OO
> programming per se - the reverse *should* be the norm.
Possibly we are talking about different OOP ideas. The one proposed in
the conventional CS departments assumes classes created on the base of
other classes (superclasses) where the choice of the superclass to
extend is based on the required minimum of augmentation to receive new
class with needed features. This way the modularity of a particular
class depends solely and exclusively on the position of such class in
the inheritance chain. If some class extends Object directly then it
is rather simple to include it directly in some other block. With a
class being on the top or even middle of the chain its inclusion also
requires the inclusion of all underlaying chain segment. Because no
educated guess can be a priori made about the position of the class X
in library Y, OO modularity overall is low - yet its maintainability
is high, as I said. It is possible to imagine (and to make) a library
where each and every class directly extends Object, no matter how
close some classes would be to each other. Just don't call it OO based
library then.
> > In OOP the
> > regular solution to the problem is having some commonly agreed core
> > libraries guaranteed to be presented and then developing own libraries
> > as extra layer(s) atop of core.
>
> The same old assertion.
"The common knowledge basics mentioning" would be more appropriate :-)
Again - unless we are talking about different OO ideas.
> > Javascript is slowly moving to this
> > direction.
>
> It is?
Yep.
> > The first necessary step was to let the market to clean up
> > the initial anarchy of N different libraries on each corner. This step
> > is pretty much accomplished as of this year, with Prototype being an
> > industry standard with jQuery second industry standard compliant
> > library.
>
> "Industry standard compliant library". That is there any such thing
> as "industry standard" in client-side browser scripting?
Of course. Say - just a small sample - make a library where $
identifier is used for your own purposes not related with DOM ID
lookup. Now try to sell it without fixing it. Report the results. ;-)
Peter Michaux
> On Apr 26, 4:01 pm, RobG <rg...@iinet.net.au> wrote:
>
> > it has been shown here that using:
>
> > var XXLIB = {
> > fnOne: function(){...},
> > fnTwo: function(){...},
> > ...
>
> > };
>
> > provides no more (and possibly less) of a "name space" than the
> > effectively equivalent:
>
> > function XXLIB_fnOne(){...}
> > function XXLIB_fnTwo(){...}
I agree there is no difference in the namespace protection gained by
either solution above. I've brought this up ocassionally on c.l.js.
The response has been that there is no namespace protection difference
but performance. (There may be a slow hashing algorithm in that
browser?) Richard Cornford wrote that at least one browser does not do
well when there are many global objects. I believe it is somewhere in
this thread
Richard seems to like a third option which I think works like this
var localFnOne = XXLIB('fnOne');
which gives the library a chance to "build" the fnOne function. This
also seems to encourage making local copies inside a function of
library functions which is faster when the function calling the
library runs. These local copies however, do seem to encourage early
binding. That is the library "fnOne" function cannot be redefined
unless there is special effort (not that difficult) in the library
design to allow for that. I've thought about Richard's system quite a
bit and haven't thought of a compelling advantage that the earlier two
version don't have.
> With the latter ("Macromedia notation") even more efficient at least
> for JScript where DispIDs are not reusable so any lookup chain
> abbreviation brings better performance. Alas the ol'good "Macromedia
> notation" is currently a victim of programming fashion. Namely it is
> "out of fashion".
As I wrote above, I have been told that some browser(s) is slower with
many global symbols. I haven't verified that myself. I much prefer the
idea of the Macromedia style as I don't use underscore and it would
could easily be reserved for the concept of namespacing and the dot
could be saved when a conceptually real OOP object with mutable state
is involved.
One thing I don't like about using a dot for namespacing is someone
might use "this" in one of the functions to refer to the namespace
object. That means local copies cannot be made trivially. For example,
var XXLIB = {
fnOne: function(){...},
fnTwo: function(){this.fnOne()},
// ...
};
and then in local code
var fnTwo = XXLIB.fnTwo;
requires using apply
fnTwo.apply(XXLIB, [])
This would be difficult to make necessary with the Macromedia solution
or with Richard's solution.
Peter
VK
> Richard Cornford wrote that at least one browser does not do
> well when there are many global objects. I believe it is somewhere in
> this thread
There is nothing obvious about this problem in the linked thread.
Maybe I looked at the wrong space? Overall name me a browser that
would _increase_ performance with more global vars created :-)
At the same time I am not aware of a browser that would be
_particulary_ bad with numerous global vars - up to the point of an
obvious productivity decrease in comparison with other browsers.
At the same time long lookup chains a.b.c.d.e.f etc. do impact
noticeably at least one browser with non-reusable DispIDs - IE/
JScript.
While preparing for sell my SVL library (Superimposed Vector Language,
a layer interface for SVG+VML) I couldn't get a satisfactory smooth
rotation of complex 3D shapes on 1.x GHz machines which was not
acceptable. Then I just rebuild the entire library in the old top
level based "Macromedia notation style" and things came to life right
away. I don't mean one could right new levels of Quake in SVL after
that :-) - but the productivity became commercially satisfactory for
the customer.
Peter Michaux
> On Apr 26, 7:42 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > Richard Cornford wrote that at least one browser does not do
> > well when there are many global objects. I believe it is somewhere in
> > this thread
> > <URL:http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...>
>
> There is nothing obvious about this problem in the linked thread.
It seems that IE6 performs very well when one level of object
namespacing is used. These results in favor of IE and a level of
object namespacing seem too good to be true. I've tried slight
variations on the tests below with similar results.
TEST ONE --------------------------------------------------------
430 ms FF2
430 ms IE6
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Test 1</title>
</head>
<body>
<script type="text/javascript">
var symbols = []
for (var i=0; i<2000; i++) {
var name = 'sym' + i;
symbols.push(name)
this[name] = function() {};
}
var tic = (new Date());
for (var i=0; i<20; i++) {
for (var j=0, jlen=symbols.length; j<jlen; j++) {
this[symbols[j]]();
}
}
document.write((new Date()).getTime() - (tic).getTime());
</script>
</body>
</html>
TEST TWO ---------------------------------------------------------
440 ms FF2
120 ms IE6 <------ Wow!
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Test 2</title>
</head>
<body>
<script type="text/javascript">
var symbols = []
var namespace = {};
for (var i=0; i<2000; i++) {
var name = 'sym' + i;
symbols.push(name)
namespace[name] = function() {};
}
var tic = (new Date());
for (var i=0; i<20; i++) {
for (var j=0, jlen=symbols.length; j<jlen; j++) {
namespace[symbols[j]]();
}
}
document.write((new Date()).getTime() - (tic).getTime());
</script>
</body>
</html>
VK
The results are amazing :-) but not for the reason you are possibly
thinking of. It doesn't matter if one has top level or level down
functions. The "slowdown key" is in using window host object in DispID
resolution. I know that you are - as many - have been zombificated by
"window = this = Global". It is not true in overall and it is
especially wrong for IE that has to be ready to accommodate and
intercommunicate two completely different languages: JScript and
VBScript. Here window acts as a mediator level between two Globals of
two engines and any intensive usage of it for DispID resolution
decreases hits the performance with a big strength. In your second
sample replace
namespace[symbols[j]]();
with
this.namespace[symbols[j]]();
and "enjoy" the result.
Also try this for fun: (just don't take it as an eval promo, please) :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Test 1</title>
</head>
<body>
<script type="text/javascript">
for (var i=0; i<2000; i++) {
var name = 'n' + i;
eval(name+'=new Function');
}
var tic = (new Date());
for (var i=0; i<2000; i++) {
var name = 'n' + i;
eval(name+'()');
RobG
> On Apr 26, 4:01 pm, RobG <rg...@iinet.net.au> wrote:
> > > OOP library usage is
> > > per library, not per method based.
>
> > programming per se - the reverse *should* be the norm.
>
> Possibly we are talking about different OOP ideas. The one proposed in
> the conventional CS departments assumes classes created on the base of
> other classes (superclasses) where the choice of the superclass to
> extend is based on the required minimum of augmentation to receive new
> class with needed features.
I was just trying to point out that that isn't necessarily a
consequence of OO programming. Similar dependencies can be created in
a library of functions that aren't object oriented where there are
dependencies of functions based on lower (or higher, depending on your
perspective) tiers of functions, which is essential what a class
hierarchy is.
> This way the modularity of a particular
> class depends solely and exclusively on the position of such class in
> the inheritance chain. If some class extends Object directly then it
> is rather simple to include it directly in some other block. With a
> class being on the top or even middle of the chain its inclusion also
> requires the inclusion of all underlaying chain segment. Because no
> educated guess can be a priori made about the position of the class X
> in library Y, OO modularity overall is low - yet its maintainability
> is high, as I said.
"Maintainability" is a double edged sword in this case. It becomes
very difficult to modify a higher level class if there are many, many
sub-classes based on it (as you said your self in regard to backwards
compatibility).
> It is possible to imagine (and to make) a library
> where each and every class directly extends Object, no matter how
> close some classes would be to each other. Just don't call it OO based
> library then.
I think the term "object based" fits javascript much better.
> > > In OOP the
> > > regular solution to the problem is having some commonly agreed core
> > > libraries guaranteed to be presented and then developing own libraries
> > > as extra layer(s) atop of core.
>
> > The same old assertion.
>
> "The common knowledge basics mentioning" would be more appropriate :-)
> Again - unless we are talking about different OO ideas.
No, I was just in a crappy mood. :-)
[...]
> > "Industry standard compliant library". That is there any such thing
> > as "industry standard" in client-side browser scripting?
>
> Of course. Say - just a small sample - make a library where $
> identifier is used for your own purposes not related with DOM ID
> lookup. Now try to sell it without fixing it. Report the results. ;-)
You might have chosen a better example, I wouldn't use $ in any part
of an identifier name in a javascript program as the projects I work
on use a large numbers of server-generated identifiers like
xyz00$pppMmmmm and xyz00$UserStatus1$FullName.
It also reminds me of other programming environments where $ has a
particular meaning. As far as I know, the usage stems from using $
(elementID) clientside and $elementID serverside. It may have seemed
cool at the time, but could be classed as a newbie mistake that never
got fixed because a whole bunch of other noobs picked up on it as
beeing cool.
--
Rob
Richard Cornford
> On Apr 22, 5:39 pm, Richard Cornford wrote:
>> On Apr 21, 10:21 pm, dhtml wrote:
>>> On Apr 19, 9:02 am, Richard Cornford wrote:
>>>> One of the arguments paraded in favour of these libraries is
>>>> that they are examined, worked on and used by very large
>>>> numbers of people, and so they should be of reasonably high
>>>> quality because with many eyes looking at the code obvious
>>>> mistakes should not go unnoticed. My experience of looking
>>>> at code from the various 'popular' libraries suggests that
>>>> this is a fallacy, because (with the exception of YUI (for
>>>> obvious reasons))
>>
>>> Not obvious.
>>
>>> There's plenty of bugs YUI.
>>
>> Who is talking about bugs? Take this code from the dojo
>> library:-
You had a choice.
> YUI has some pretty bad/obvious bugs in crucial places.
> augmentObject, hasOwnProperty. Dom.contains:-
>
> hasOwnProperty: function(o, prop) {
> if (Object.prototype.hasOwnProperty) {
> return o.hasOwnProperty(prop);
> }
>
> return !YAHOO.lang.isUndefined(o[prop]) &&
> o.constructor.prototype[prop] !== o[prop];
> },
>
> - Which will throw errors in IE when - o - is a host
> object and return wrong results in Opera when - o - is
> window. augmentObject:-
So? Does the documentation propose that this method is objects other
than native ECMAScript objects?
> augmentObject: function(r, s) {
> if (!s||!r) {
> throw new Error("Absorb failed, verify dependencies.");
> }
> var a=arguments, i, p, override=a[2];
> if (override && override!==true) { // only absorb the
> specified properties
Why do you find it so difficult to cope with posting code that is not
mangled by line wrapping?
> for (i=2; i<a.length; i=i+1) {
> r[a[i]] = s[a[i]];
> }
> } else { // take everything, overwriting only if the
> third parameter is true
> for (p in s) {
> if (override || !r[p]) {
> r[p] = s[p];
> }
> }
>
> YAHOO.lang._IEEnumFix(r, s);
> }
> },
>
>
> It is questionable strategy to do object augmentation
> on the prototype chain of the supplier.
So a "questionable strategy" not a bug?
> It would be better to use hasOwnProperty to
> filter the stuff in the supplier's prototype chain out.
No, it would not. It may, under some circumstances, be better, but it
also may not be; it depends on what outcome you are after.
> Next, if the receiver has a property p with a false-ish
> value, then the ovveride flag is irrelevant.
That may be how the code was programmed, but what makes it a bug?
> Dojo calls object augmentation "extend" which to me seems
> to be misleading.
Misleading code may not be great, much as obscure code may not be great,
but where are the bugs you spoke of?
What does the documentation have to say about the expected arguments?
> Though the last is not as obvious a mistake as the others.
So there was no evidence of any bugs in the others and this one is less
obvious than they were?
> There are considerably questionable practices in the Event
> library.
What have "questionable practices" got to do with your suggestion that
you may be presenting "pretty bad/obvious bugs in crucial places"?
> The connection manager is horribly designed. The fact that
> it attempts to do form serialization within iteself, is
> just a horrible decision. If the author had been forced
> to write a test for that, he'd probably have moved that
> form serialization code somewhere else, to make it easier
> to test (easier coverage verification).
So you don't see the difference between writing code that logically
cannot be executed and your opinions about how things should be
designed? Unfortunately your not perceiving that distinction goes quite
some way towards bring into question your opinions on how code should be
designed.
> [snip]
>
>> And where those
>> authors are part of a collective they don't speak for the
>> knowledge of the specific author responsible but instead
>> indicate the level of understanding of the _most_
>> knowledgeable person involved.
>>
>
> This can lead to blocking code reviews and scape goating.
What "can lead to ..."?
> With a test driven approach, the only thing to blame is the
> process, and that's fixable (besides the fact that the test
> never has any hard feelings).
A test driven approach helps nothing when the people designing those
tests are not capable of stressing their code to the point of showing
how were and why it falls over.
> Without tests, you get things like blood commits and code
> freezes. Some libraries actually do code freezes. And they
> have at least one expert. And they have bugs. Dumb ones.
So if YUI is not the library with these bugs (just "questionable
practices", in your opinion) why aren't you naming it here?
>> <snip>
>>
>>> A fix for the bug that was demonstrated seems to be by
>>> simply putting the & last.
>>
>>> String.prototype.unescapeHTML = function() {
>>> return this.replace(/</g,'<')
>>> .replace(/>/g,'>')
>>> .replace(/&/g,'&');
>>> };
>>
>> > That would need to be tested out though.
>>
>> No it does not need to be test, it is correct. The general
>> rule is that the character significant in escaping needs to
>> be processed first when escaping and last when unescaping.
>>
>
> It addresses the problem that was demonstrated in your
> example. It does not, however, take into consideration
> the possibility that - this - could contain * any * other
> entities.
No, but it was not coded to do that.
> If the need to handle - " - or & (which is also
> '&') got added in later, they'd need to be reviewed by the
> one, sole expert, to make sure the person who wrote the
> amending code didn't make a rookie mistake. A test could
> clearly prove it worked.
Obviously.
> var s = """.replace(/"/g, '"');
>
> So the fix addresses only one concern.
Yes, it addresses the thing that stops the pair of encoding/decoding
methods being symmetrical.
> another consideration is that String.prototype.escapeHTML
> should be stable, but if there's a bug, and dependencies on
> that bug, then the fixing of the bug becomes complicated.
> In may very well be the case that some novice programmer used
> escapeHTML, found that it didn't work right, made some
> adjustments in his implementation to compensate for that bug.
> In essence, his implementation is now depending on that bug.
> This is where I see adding things to built-in prototypes to
> be risky.
That is a truly lousy argument for not augmenting built-in prototypes,
as it is just as true for any aspect of any public API in any
general-purpose library.
> If the programmer had made a method, then that method
> could always be deprecated in a future release, if found
> to be problematic.
What is to stop a library that augments the built-in prototypes from
deprecating the methods it adds to the prototype?
> So, to sum it up, my recommentations:
> 1) write a test
A reasonable suggestion, but a little superficial. The assertion is that
there was a test for these methods, but that in itself did not expose
the issue.
> 2) don't put the methods on String.prototype because they
> might change later.
You might as well say 'don't put methods anywhere as they might change
later'.
>>> Right?
>>
>> Absolutely. It is a simple bug, and a mistake that in my
>> experience is made by nearly every programmer who comes to
>> the issues of encoding/escaping for the web for the first
>> time (pretty much no matter what their previous level of
>> experience in other areas). It is something that I have
>> learnt to double check, habitually, and that is the reason
>> that I spotted it so quickly.
>>
> That was my first time writing an unescape function in
> Javascript.
But you did have the advantage of knowing that there was something up
with the code as it had been written, which usually makes finding and
fixing an error easier.
> I think I might have written one in Java several years ago
> in a response filter exercise, though.
>
> If I had to write something more comprehensive to account
> for more entities, I'd probably consider looking into
> inverting control to the browser's parser using a combination
> of newDiv.innerHTML and newDiv.textContent|innerText
That is what Prototype.js's other versions of this method do (hence the
cross-browser inconsistencies as it means that those methods will
handle other entities where these version will not).
> document.body.textContent = "&";
> document.body.innerHTML; // &
>
> document.body.innerHTML = """
> document.body.textContent; // "
>
> Obviously not using document.body, but a newly created node.
> I would probably write some tests for that, including the
> cases you posted, make sure they all fail, then write out
> some code (the code could be changed in the future, since
> there are tests).
A general entity encoding/decoding method is probably either over the
top or totally unnecessary for most real-world contexts.
Richard.
Richard Cornford
>On Apr 22, 7:39 pm, Richard Cornford wrote:
>> Andrew Dupont wrote:
>>> On Apr 19, 11:07 pm, Richard Cornford wrote:
>>>> Who is going to be deciding what 'constructive' means in
>>>> this context?
>>
>>> Each individual on his own.
>>
>> Maybe, but there are circumstances were the best advice possible
>> is to delete something and start again from scratch, but most
>> individuals who hear that advice don't regard it is constructive
>> when they do.
>>
>>> Or, in other words: say what you want to say, and I'll
>>> brush off anything I think is unwarranted.
>>
>> Presumably you mean you will brush off anything that you regard
>> as unwarranted?
>
> How is that different?
I will take that as a "yes". It does bring in to question the worth of
my saying anything at all.
>>> I'm not
>>> setting conditions for prior restraint here.
>>
>> Requiring what you get to be "constructive" is not a condition?
>
> You're hyper-parsing my statements. I think the response the OP
> got _isn't constructive_ clearly you disagree.
If someone is going to make a mistake then being told that it is a
mistake certainly can be regarded as constructive, even if not as
constructive as being told why it may be a mistake.
> I think some of
> the criticism of Prototype that occurs in this newsgroup _isn't
> constructive_, but some _is_. I am saying that I will disregard
> things that I don't feel are constructive. Therefore there is no
> "requirement" of any sort. Jesus.
But anyone then asserting that, for example, the best way forward with
Prototype.js would be to delete it and start again from scratch will be
disregarded even if they think that advice is constructive (and it is
virtually the only way that it would be possible to correct the mistake
of violating the language's specification's injunction against using the
'$' symbol as the initial character in Identifiers except when they were
machine generated).
>>>> You mean that if someone is in a 'minority' then they must
>>>> be wrong? That is hardly an attitude that would allow
>>>> progress through the adoption of new ideas.
>>
>>> I never said anything of the sort. I said the minority need
>>> to do more _persuading_.
>>
>> OK. Why, what is in it for them?
>
> Nothing. Go eat a taco if you like.
You wrote "... they obviously need to do more persuading", but not there
appears to be no obvious necessity here.
>>> You stated that these libraries were junk
>>
>> I very much doubt that I did.
>
> Somewhere along the way I got you mixed up with Thomas. For that
> I apologize.
>
>>> Clearly it isn't common knowledge.
>>
>> There are lots of things that are true but are not common
>> knowledge.
>
> I'm not arguing whether it's true or not. If I say "Martin
> Scorsese can't direct for shit," I expect people around me to
> look at me funny, because whether my statement is true or not
> it goes against consensus. Therefore I might feel a burden to
> _elaborate_.
But would you still feel the need to elaborate in the company of people
who shared that opinion?
>> Maybe, but there is an objective "better" in the sense of
>> using:-
>>
>> if(elem == null){
>> dojo.raise("No element given to dojo.dom.setAttributeNS");
>>
>> }
>>
>> - in place of:-
>>
>> if(
>> elem == null ||
>> ((elem == undefined)&&(typeof elem == "undefined"))
>> ){
>> dojo.raise("No element given to dojo.dom.setAttributeNS");
>>
>> }
>
> And you seem to say that a small handful of silly choices in
> a framework mean the entire thing is worthless.
No, I am saying that when the people who designed frameworks/libraries
and the like are demonstrating fundamental shortfalls in the
understanding of the language they are using then the consequences of
that evident ignorance are likely to also manifest themselves in the
overall design of those frameworks/libraries. That is, they are
indicative of the consequences of design decisions (which may themselves
be regarded as largely subjective) being as uninformed (by both
knowledge and experience) and so that the whole of which they are a part
being in some sense 'junk'.
>>>> How do you know that? It seems likely to me that Thomas
>>>> was using his memory of the many (more or less detailed)
>>>> discussions of Prototype.js code that have happened here
>>>> over the past few years to inform a general assessment
>>>> of the code.
>>
>>> And I submit that is a matter of taste.
>>
>> Thomas's memory is a matter of taste?
>
> No, his assessment is a matter of taste. The part that
> connects his memory and his opinion.
For some reason my memory connects the notion of genocide with "really
very bad", but I suppose that is just a matter of taste.
>> Not really. There are bugs and there are bugs. A typo in the
>> middle of a large block of code is something that can happen
>> to anyone, and it could also easily be missed by others
>> reviewing that code. A glaring error in something that
>> experience would teach you to always double check and also
>> should be exposed in any reasonable testing is something else
>> entirely.
>
> We disagree on the degree to which this is important. I think
> we've gone as far as we can on this point.
Probably.
>>> of course, and we welcome bug reports. But you've gone
>>> further than that; you've inferred from "evidence" that
>>> code in Prototype does not do what its author means for
>>> it to do.
>>
>> No, I said that the evidence was that Prototype.js was (at
>> least in November last year) only doing what was (apparently)
>> expected by coincidence; that it had not actually been
>> programmed to do what it was doing. I also implied that were
>> that evidence existed it was reasonable to question the
>> understanding of javascript that informed all of the design
>> decisions that occurred prior to that code being written;
>> such as the underlying design approach and the resulting API.
>
>> (I have also pointed out that Prototype.js is incredibly slow
>> at doing pretty much anything complex)
>
> That's a very vague statement. A few examples would be greatly
> appreciated.
Examples of what precisely?
> The words "slow," "anything," and "complex" are
> relative to the individual,
Only to a limited degree. They are more relative to the words "fast"
"nothing" and "simple", respectively.
> and obviously must be taken into
> account when making a technology decision. jQuery's central
> API focus - fetching nodes by CSS selector - means that a
> line of jQuery code is often much slower than the equivalent,
> non-framework-aided code.
Yes, occasionally someone shows up here and complains that attempting to
sort 10,000 table rows is unacceptably slow. To which there is little
choice but to say that that is how it is and you deal with that by
designing the need to sort 10,000 table rows out of the system (a
response that is generally not taken as being constructive, despite
being the best advice going). I have seen people complaining that
JQuery's performance is unacceptable with as few as 400 table rows to
sort.
> Many people use it anyway because
> they deem it to be worth the trade-off.
To judge a trade-off it is necessary to know and understand the
alternatives. I suspect that the majority using these things are doing
so in order that they don't have to learn the alternatives and so carry
on using them regardless not as a result of assessing a trade-off but
rather because they have no real alternative.
<snip>
>>> You know the point I'm trying to make.
>>
>> Not really.
>
> Apparently I need to stop using sarcasm. I also need to stop
> speaking abstractly, aside from basic declaratives (e.g.,
> "Your tone is too harsh."). You are reading the most literal
> of meanings into every single word I write.
Reading literally. Literally?
>>>> ... . There is a lot to be said for the uncensored
>>>> exchange of ideas in public.
>>
>>> The word "censorship" doesn't come within miles of this
>>> thread.
>>
>> Well this is Usenet so there is no censorship.
>>
>>> I do not own a telecommunications company; I don't have
>>> the means or authority to "censor" anyone.
>>
>> You would not have the means to censor Usenet even if you
>> did own a telecommunications company.
>
> Case in point. I don't know why you think I was trying to
> censor conversation in the first place.
I did not think you were trying to censor anything (beyond those things
that you will 'brush off' as a result of their not being 'constructive',
but that is only going to impact on you so it does not really count). I
observed that there were considerable advantages in the exchange of
ideas being censorship free, despite the fact that the consequences of
that may include the odd post here or there being a knee-jerk
generalisation rather than a reasoned argument.
> My point is that
> I can't (and don't want to) censor anything.
Beyond those things that you will 'brush off' as a result of their not
being 'constructive'.
>>> I mean that they weren't participants before their first
>>> post.
>>
>> And they weren't human before they were conceived.
>
> Needlessly argumentative and willfully dense to the point
> I'm making.
Try making your point in as many words.
<snip>
>>> Please search this newsgroup for the terms "Prototype"
>>
>> What are you expecting? You give a library the same name as
>> a significant aspect of the language it written in and then
>> cannot find specific references to it in the archives of a
>> newsgroup dedicated to that language. It was a predictably
>> bad choice of name.
>
> Again, argumentative. The fact it's a bad name for a library
> (which I agree with) is unrelated to the point I am making.
I thought that the point you were making was that attempting to look up
"prototype" in the archives resulted in such a food of responses that
fining the substance that (may or may not) inform the 'junk' assessment
was not practical.
>>> and/or "jQuery" and see how quickly you find a well-summarized
>>> critique of either library.
>>
>> Who said finding that sort of thing out was going to be quick?
>> I bet the search would still turn out to be informative even
>> if it could not be instantaneous.
>
> This is like saying I ought to read the entirety of Donald Knuth's
> published works before I write a simple algorithm.
More like saying that you maybe ought to read at least one book by
Donald Knuth before putting yourself forward as an arbiter of algorithm
correctness.
> You may be right in your "bet," but that's not how a user in
> need of help is going to _behave_, so what's the user of
> pretending otherwise?
What has a "user" to do with anything? The purpose of this group is not
to help individuals with their problems (to the extent that that happens
at all it is no more than a side effect of the group). The group exists
to allow its participants to discuss javascript, and the reason that its
participants want to discuss javascript is to improve their own
understanding of the subject. All the question asking and answering is
just a convenient mechanism for getting the ball rolling (and carries on
because the vast majority of questions get reasonable good answers
(eventually)).
So you are not continuing to argue about "technically baseless" or
"ineffective"? Certainly you are not pointing out the location of the
technical basses for UA string based browser sniffing for all to see.
> We sniff
> to distinguish between other browsers (e.g., between Gecko and
> WebKit),
And for two years I operated IE 6 with the word 'Gecko' in its UA header
(in order to render MSDN usable), and at no point during that time was I
in violation of HTTP 1.1.
> but we use a different heuristic for IE.
The test you are using for IE is an object inference test along the
following lines of:-
IE: !!(window.attachEvent && !window.opera),
- and that betrays its own folly. The reason for including the -
!window.opera - bit that Opera's creators have seen expedience in
providing their browser with 'IE compatibility' features. The problem
with that is that the same rational that motivated Opera's creators may
influence the manufacturers of any other web browser. And so any browser
may potentially have an - attachEvent - method of the window object, and
in the even that any do they are unlikely to bother to implement a -
window.opera - object as well (because Opera compatibility is not going
to be a worthwhile path to pursue). Object inference may by a marginally
superior strategy to UA string based browser detection but it is
predicated upon such a detailed and broad knowledge of web browser
object models that the only way of seeing it as a valid strategy would
be to pretend that there were only 3 or 4 browsers in existence.
> Second: your gripe seems to be that we use any
> heuristic at all - that it's not possible to detect
> differences in UAs with 100% accuracy.
You make it sound like browsers can be differentiated with some degree
of accuracy. User Agent string based browser sniffing cannot
differentiate between browsers that use the same sequence of characters
in their User Agent headers, and cannot handle unexpected header content
(despite there being no technical grounds for expecting anything
specific in any such header). Object inference is only ever as good as
the direct (and detailed) knowledge of browser object models, and a more
detailed knowledge than the majority of those attempting it demonstrate
in the tests they devise. And it suffers from necessitating much ongoing
code maintenance because knowledge of browser object models can only be
knowledge of existing browser object models, so not even including the
next version of any existing browser let alone any new browsers that may
come into existence.
History has already exposed the fact that object inference browser
detection sows the seeds of its own invalidity. It is no accident that
browsers have been observed that implement an - ActiveXObject - global
function even though they were designed to be cross-OS (and you cannot
instantiate an ActiveX object on non-Windows OSs). It was a direct
consequence of javascript authors attempting to use the existence of
that object to infer that a browser was IE, and so turn otherwise
perfectly usable browsers into apparently non-functional browsers. The
manufacturers of those apparently non-functional browsers then become
well motivated to spoof enough of the IE object model to fool such
tests.
> 99.99% accuracy is good enough for me. I'm not insisting
> that you must agree;
That may be acceptable if it could be known to be 99.99% (or even
something approaching it), but that is no more than a guess, and a
very flawed guess at that. Where would that number come from, if
not derived from web browser usage statistics? Even disregarding
the inherent issues with statistics gathering over HTTP (the
unknowable and probably inconsistent influence intermediate caches
being just one) and the self-biasing nature of browser usage
statistics, the browser identification issue remains. Browser
usage statistics use User Agent string based browser sniffing
(with a few throwing in some rudimentary object inference
testing). Which means that if you used browser usage statistics
to justify your guess of 99.99% accuracy of your browser
identification techniques you would be implying that those browser
usage statistics were, more or less, accurate despite their
employing pretty much the same techniques. That is, the accuracy
of the techniques you use would be being justified by the
assumption that those same techniques were accurate. But if
they are not accurate then there is nothing to justify your
claims of 99.99% accuracy. Making that a somewhat circular
argument.
> I'm only asking not to be regarded as a savage.
You will have to make that particular appeal to a different audience.
>> So you would not be certain what the code was going to do, but
>> you would know that whatever it did it would take about the
>> same amount of time to do it wherever it was running? I
>> certainly do not have a taste for that design philosophy.
>
> No, I would rely on the unit tests to demonstrate a consistent
> behavior. It doesn't give me 100% certainty because I can't
> test every string on earth. (In this case, obviously, we didn't
> test enough strings.)
More like you did not write the unit test such that they exposed to code
to input that was likely to be miss-handled. But that was just the
consequence of the experience shortfall that mentioned previously (and
you deny exists at all).
>>>> But I suppose that you would not agree that being able to
>>>> find an obvious rookie mistake in less then three seconds
>>>> of looking (at a library that is already a good few years
>>>> old) tends to support the "junk" assessment.
>>
>>> The check-in is only one year old. It is Thomas's bug, but
>>> he is no rookie,
>>
>> Hansom is as hansom does. But that was not really my point.
>> One of the things that gets proposed as a justification for
>> libraries of this sort (a reason for their not being junk by
>> virtue of what they are) is that with many individuals
>> contributing there are plenty of eyes looking at the code
>> to be able to find these sorts of things and fix them up front.
>> But if it takes me three seconds to find what nobody else had
>> noticed then it must be the case that there is nobody involved
>> looking with my eyes.
>
> Again: someone else did notice it. But it did go unfixed for
> about a year, and I find that disappointing and unusual. We
> agree on the former but not the latter.
>
>>> We listen to criticism, we read bug reports, and we
>>> constantly search for ways to improve the feedback loop.
>>
>> That all sounds very 'marketing-speak'.
>
> Again, you're being oddly argumentative. I don't care how it
> sounds to you.
And I would rather not see this type of BS at all (and even if nothing
else is "constantly" certainly is BS).
>>> So does John Resig, by the way, so I'd suggest you file a bug
>>> on jQuery's Trac about the "makeArray" mistake.
>>
>> Why? Polishing the handrails on the Titanic may have made it
>> more appealing to look at but didn't change the rate at which
>> it sank after the design flaw coincided with the iceberg.
>
> Are you sure?
Yes, the Titanic's problems were in the fundamental design not how shiny
the trimmings were.
> The bug submission screen has a gigantic text box in which
> you can make any sort of condescending judgment you like.
> How can you resist?
Very easily.
Richard.
VK
wrote:
> But anyone then asserting that, for example, the best way forward with
> Prototype.js would be to delete it and start again from scratch will be
> disregarded even if they think that advice is constructive (and it is
> virtually the only way that it would be possible to correct the mistake
> of violating the language's specification's injunction against using the
> '$' symbol as the initial character in Identifiers except when they were
> machine generated).
So are you proposing to trash out a whole library because one of used
identifiers is _not suggested_ yet fully valid? IMO it is an act of
lunatism. Prototype.js has a number of its defaults - but making $
usage as the main reason to drop it makes the poster look ridiculous.
And the least I want to see in c.l.j. is _Richard Cornford_ looking
ridiculous or funny. Upset, sarcastic, nasty - any time, just please
don't make fun of yourself. Can you switch on some _substantional_
library criticism instead?
Peter Michaux
wrote:
> But anyone then asserting that, for example, the best way forward with
> Prototype.js would be to delete it and start again from scratch will be
> disregarded even if they think that advice is constructive (and it is
> virtually the only way that it would be possible to correct the mistake
> of violating the language's specification's injunction against using the
> '$' symbol as the initial character in Identifiers except when they were
> machine generated).
ES3 spec:
"The dollar sign is intended for use only in mechanically generated
code."
Both "intended" and "mechanically generated" make the sentence
ambiguous. It is only a recommendation at best.
Since ES is a spec that is based on existing implementations and
language use, I think the safe bet is that such a reservation about $
in identifiers will be removed when ES4 is published.
Peter
Richard Cornford
> On May 5, 4:26 pm, Richard Cornford wrote:
>
>> But anyone then asserting that, for example, the best way
>> forward with Prototype.js would be to delete it and start
>> again from scratch will be disregarded even if they think
>> that advice is constructive (and it is virtually the only
>> way that it would be possible to correct the mistake of
>> violating the language's specification's injunction against
>> using the '$' symbol as the initial character in Identifiers
>> except when they were machine generated).
>
> ES3 spec:
>
> "The dollar sign is intended for use only in mechanically
> generated code."
>
> Both "intended" and "mechanically generated" make the sentence
> ambiguous.
Not that ambiguous (and particularly with the word "only" in there).
That sentence explains why a character that really did not need to be in
the set of characters allowed in identifiers was included in that set.
> It is only a recommendation at best.
Yet the reaction to an almost identical assertion about Java identifiers
in its specification results in Java programmers finding the idea of
using a $ symbol unthinkable; something that only complete novices and
armatures would do, and an error that would stamped out as soon as they
got into a professional context.
> Since ES is a spec that is based on existing implementations
> and language use, I think the safe bet is that such a reservation
> about $ in identifiers will be removed when ES4 is published.
ES4 looks like it is going to be a serious (if predictable) mistake. How
much of a mistake will not be clear until there is a specification to
read.
Richard.
dhtml
wrote:On May 5, 4:26 pm, "Richard Cornford"
> dhtml wrote:
> > On Apr 22, 5:39 pm, Richard Cornford wrote:
> >> On Apr 21, 10:21 pm, dhtml wrote:
> >>> On Apr 19, 9:02 am, Richard Cornford wrote:
> > I really didn't want to be goaded into postup a dumb and
> > dumber competition with other people's code, but you've left
> > me with not very good choices.
>
> You had a choice.
>
I made a choice.
> > YUI has some pretty bad/obvious bugs in crucial places.
> > augmentObject, hasOwnProperty. Dom.contains:-
>
> > hasOwnProperty: function(o, prop) {
> > if (Object.prototype.hasOwnProperty) {
> > return o.hasOwnProperty(prop);
> > }
>
> > return !YAHOO.lang.isUndefined(o[prop]) &&
> > o.constructor.prototype[prop] !== o[prop];
> > },
>
> > - Which will throw errors in IE when - o - is a host
> > object and return wrong results in Opera when - o - is
> > window. augmentObject:-
>
> So? Does the documentation propose that this method is objects other
> than native ECMAScript objects?
>
Doesn't say one way or the other. The author might not have been aware
of the differences with native vs host objects when he wrote:
if (Object.prototype.hasOwnProperty) {
return o.hasOwnProperty(prop);
}
It is unsafe to assume that just because
Object.prototype.hasOwnProperty, then o.hasOwnProperty will also be a
method.
It would be safer to use:
if (Object.prototype.hasOwnProperty) {
return Object.prototype.hasOwnProperty.call(o, prop);
}
And I'd really like to hear some others' have to say on that one.
But better yet:
if (typeof o.hasOwnProperty == "function") {
return o.hasOwnProperty(prop);
}
Because then there is no need to concern about what type of object is
passed. Is it a host object? A native Object? Who cares? As long as
that hasOwnProperty method is on the object that is passed in, then
try and use it. It's not 100% safe because it's entirely possible to
have the hasOwnProperty method shadowing the one on Object.prototype.
// Rediculous example.
liar.hasOwnProperty = function(p) { return !
Object.prototype.hasOwnProperty.call(this, p);};
liar.hasOwnProperty('hasOwnProperty'); // false.
liar.hasOwnProperty('toString'); // true.
It's a fairly common assumption that an object is an object. Mozilla
goes to some trouble to make Host objects work like an Object object.
In fact, speak of the Devil, I can look at Prototype right now and
find something that looks like it could potentially be augmenting a
Host object.
if (!Node.ELEMENT_NODE) {
// DOM level 2 ECMAScript Language Binding
Object.extend(Node, {
Some programmers write code that could potentially augment a Host
object. If augmentObject should never be used with a Host object, then
why not just call Object.prototype.hasOwnProperty.call(o, p), and
write a comment:-
// Not guaranteed to work on Host object, e.g. document.body.
> > augmentObject: function(r, s) {
> > if (!s||!r) {
> > throw new Error("Absorb failed, verify dependencies.");
> > }
> > var a=arguments, i, p, override=a[2];
> > if (override && override!==true) { // only absorb the
> > specified properties
>
> Why do you find it so difficult to cope with posting code that is not
> mangled by line wrapping?
>
I wasn't finding much difficulty in it, thanks.
j/k. Got your point.
>
>
> > for (i=2; i<a.length; i=i+1) {
> > r[a[i]] = s[a[i]];
> > }
> > } else { // take everything, overwriting only if the
> > third parameter is true
> > for (p in s) {
> > if (override || !r[p]) {
Here is the bug...................^
> > r[p] = s[p];
> > }
> > }
>
> > YAHOO.lang._IEEnumFix(r, s);
> > }
> > },
>
> > It is questionable strategy to do object augmentation
> > on the prototype chain of the supplier.
>
> So a "questionable strategy" not a bug?
>
It is an unexpected behavior that can lead to unexpected consequences.
This should be clearly stated in the comments. It's something that the
user/client has to be aware of when using this method. There's no
discerning between shadowing and replacing, so it's entirely possible
that the receiver has a property - 'isOpen' - maybe in the prototype
chain, and the supplier has a property 'isOpen', but overrides is set
to false. The clients might expect receiver to get the supplier's
'isOpen' property, but if overrides is false, it won't happen. It will
only happen when overrides is true and 'isOpen' is not a value that
evaluates to false in a boolean context.
What's worse, when they go to the _IEEnumFix, the overrides flag is
omitted.
That's two bugs, and an unjustified, undocumented design (augmenting
on the prototype, which I think might be a careless error).
> > It would be better to use hasOwnProperty to
> > filter the stuff in the supplier's prototype chain out.
>
> No, it would not. It may, under some circumstances, be better, but it
> also may not be; it depends on what outcome you are after.
>
That is true. It would complicate things, though. That there is no
comment, example, or testcase, indicating this, I would say that it
seems likely to be a mistake.
I'll give this one an 'innocent' verdict, as the comment is too vague
at the intent of the code. I don't like that.
However, there is one more point to this complicated function:
* @param {String*|boolean} arguments zero or more properties
methods
* to augment the receiver with. If none specified,
everything
* in the supplier will be used unless it would
* overwrite an existing property in the receiver. If true
* is specified as the third parameter, all properties will
* be applied and will overwrite an existing property in
* the receiver
They've documented a name of an argument as -arguments-, which must be
a mistake, but whatever. It's arguments[2].
What if - r - has a property in it's prototype chain (with a true-ish
value)?
What does 'overwrite' mean? Replace or shadow? In the code, it seems
to mean either one, apparently.
> > Next, if the receiver has a property p with a false-ish
> > value, then the override flag is irrelevant.
>
> That may be how the code was programmed, but what makes it a bug?
>
It is a bug because it does not do what it says. Specifically,
r = { a : 2 };
s = { a : 1 };
r.a will not be 1. It will stay as 2. (expected).
javascript:void((function(){ var r = {a:2}, s ={a:1} ;
YAHOO.lang.augmentObject(r, s); alert(r.a); })())
But,
r = { a : 0 };
s = { a : 1 };
Yahoo.lang.augmentObject(r, s);
r.a will be 1, even though override was not true. This is the bug.
javascript:void((function(){ var r = {a:0}, s ={a:1} ;
YAHOO.lang.augmentObject(r, s); alert(r.a); })())
+1 bug.
Another bug that I mentioned is that overrides is ignored in
_IEEnumFix. So, if you want to preserve Object.prototype.toString on
the receiver, then overrides would be false (default). Then if the
supplier has a toString or valueOf property in the prototype chain, it
gets copied over. But only in IE. Well, not always. If Opera (or any
other browser) is set to mask as IE, then that will be true in Opera.
Conservatively, that would be two bugs, given the bad browser
detection.
+2 bugs = 3 bugs.
> > Dojo calls object augmentation "extend" which to me seems
> > to be misleading.
>
> Misleading code may not be great, much as obscure code may not be great,
> but where are the bugs you spoke of?
>
I'm stopping with YUI right now.
I think I remember some weird results from dojo.coords method with a
scrolled window. Maybe I'll come back to that later.
" Determines whether an HTMLElement is an ancestor of another HTML
element in the DOM hierarchy."
I'm not certain now if you were unaware of this, or maybe you're
leading me down a blind alley, but the way contains() works in IE is
that if the argument is the same node, it returns true.
javascript:alert(YAHOO.util.Dom.isAncestor(document.body,
document.body));
true in IE, yet false in other browsers. That is a bug.
Because in IE, document.body.contains( document.body ) - is true.
+1 bug = 4 bugs.
> > Though the last is not as obvious a mistake as the others.
>
> So there was no evidence of any bugs in the others and this one is less
> obvious than they were?
>
There are 4 bugs that you were unable to spot. I'm surprised.
The other bugs are more logical and javascript misunderstanding
errors. They have nothing to do with proprietary methods on host
objects (contains()). It is a forgivable mistake, and IMO the IE
contains() method result seems strange.
> > There are considerably questionable practices in the Event
> > library.
>
> What have "questionable practices" got to do with your suggestion that
> you may be presenting "pretty bad/obvious bugs in crucial places"?
>
> > The connection manager is horribly designed. The fact that
> > it attempts to do form serialization within iteself, is
> > just a horrible decision. If the author had been forced
> > to write a test for that, he'd probably have moved that
> > form serialization code somewhere else, to make it easier
> > to test (easier coverage verification).
>
> So you don't see the difference between writing code that logically
> cannot be executed and your opinions about how things should be
> designed?
I see the difference.
> Unfortunately your not perceiving that distinction goes quite
> some way towards bring into question your opinions on how code should be
> designed.
>
It absolutely does bring into question my opinion on how code should
be designed. I've gone into more detail.
> > [snip]
>
> >> And where those
> >> authors are part of a collective they don't speak for the
> >> knowledge of the specific author responsible but instead
> >> indicate the level of understanding of the _most_
> >> knowledgeable person involved.
>
> > This can lead to blocking code reviews and scape goating.
>
> What "can lead to ..."?
>
Having one expert and making the code go through that guy leads to
this type of situation. It also leads to that guy being in a position
that is likely going to give him the kind of power that might make
people not like to work with him, should he be careless or rude in his
judgement.
YUI does (or used to) do code freezes. This is inefficient because it
slows down changes that could have been safely made, had there been a
thorough test suite in place.
> > With a test driven approach, the only thing to blame is the
> > process, and that's fixable (besides the fact that the test
> > never has any hard feelings).
>
> A test driven approach helps nothing when the people designing those
> tests are not capable of stressing their code to the point of showing
> how were and why it falls over.
>
It helps when they learn to look at the code in a less optimistic,
more critical way. That is part of testing. The code in question, the
escapeHTML, did not test the sad path. You seem to notice these things
a lot. Testing does encourage this type of mentality of "what if I do
XXX". Formal unit tests really do encourage looking at the code from
many angles, then testing all those angles, in one suite. It leads to
the discovery of bugs, which increases the code quality. It changes
the developer's mindframe to try and break the code. Testing makes
change a lot easier, too. This is an interesting blog entry that I
found: http://blog.objectmentor.com/articles/2007/10/20/architecture-is-a-second-order-effect
> > Without tests, you get things like blood commits and code
> > freezes. Some libraries actually do code freezes. And they
> > have at least one expert. And they have bugs. Dumb ones.
>
> So if YUI is not the library with these bugs (just "questionable
> practices", in your opinion) why aren't you naming it here?
>
>
1. 4 bugs here. And plenty more in the sourceforge bugtracker. (of
course, there are bugs that aren't bugs, but misunderstandings there,
and QA will file such "bugs", too). There's also an internal bugzilla
in Yahoo that is a little better, both the UI and the quality of bug
reports.
2. I did.
>
> >> <snip>
>
> >>> A fix for the bug that was demonstrated seems to be by
> >>> simply putting the & last.
>
> >>> String.prototype.unescapeHTML = function() {
> >>> return this.replace(/</g,'<')
> >>> .replace(/>/g,'>')
> >>> .replace(/&/g,'&');
> >>> };
>
> >> > That would need to be tested out though.
>
> >> No it does not need to be test, it is correct. The general
> >> rule is that the character significant in escaping needs to
> >> be processed first when escaping and last when unescaping.
>
> > It addresses the problem that was demonstrated in your
> > example. It does not, however, take into consideration
> > the possibility that - this - could contain * any * other
> > entities.
>
> No, but it was not coded to do that.
>
It was not. The requirements change. I'm not advocating ambiguous
generality, but having a test ensures that the guy who goes and make
the change at the 11th hour (or maybe after happy hour) can push a
button and get a green or red light. It also clarifies the contract of
what the method does. It's DbC, in a separate layer: A test suite.
The escapeHTML function might want to consider the entity could be
&
They are deprecable, but. I'm going to have to come back to that.
> > So, to sum it up, my recommentations:
> > 1) write a test
>
> A reasonable suggestion, but a little superficial. The assertion is that
> there was a test for these methods, but that in itself did not expose
> the issue.
>
> > 2) don't put the methods on String.prototype because they
> > might change later.
>
> You might as well say 'don't put methods anywhere as they might change
> later'.
String should be more stable because it is built in. I'm not sure why
and I can't justify this, but something about it just doesn't feel
right. Now I could be really subjective and say that having
String.prototype.trim is justified because we all know what trim()
means and because trim is probably going into ES4, too (From memory,
but I might be wrong on that).
A method on something like Menu could be less stable. Menu wouldn't
have as many dependencies, other than implementation code. Changing
things that Menu depends on, however, would be a different story.
Changing the lower-level components (which might include String) --
things which might have other dependencies, such as Form, Tooltip,
Transport, would be harder to manage.
>
> >>> Right?
>
> >> Absolutely. It is a simple bug, and a mistake that in my
> >> experience is made by nearly every programmer who comes to
> >> the issues of encoding/escaping for the web for the first
> >> time (pretty much no matter what their previous level of
> >> experience in other areas). It is something that I have
> >> learnt to double check, habitually, and that is the reason
> >> that I spotted it so quickly.
>
> > That was my first time writing an unescape function in
> > Javascript.
>
> But you did have the advantage of knowing that there was something up
> with the code as it had been written, which usually makes finding and
> fixing an error easier.
>
Yep. It's looking at the code with a different mindset. Find the
error.
> > I think I might have written one in Java several years ago
> > in a response filter exercise, though.
>
> > If I had to write something more comprehensive to account
> > for more entities, I'd probably consider looking into
> > inverting control to the browser's parser using a combination
> > of newDiv.innerHTML and newDiv.textContent|innerText
>
> That is what Prototype.js's other versions of this method do (hence the
> cross-browser inconsistencies as it means that those methods will
> handle other entities where these version will not).
>
I did look at it after posting on the thread here and noticed that,
too. That approach can have significantly inconsistent results, no
doubt, depending on the input and the browser.
[snip]
Garrett
> Richard.