third-party libraries

[Jeff North]

Re: third-party libraries

On Mon, 27 Aug 2007 15:06:28 +0200, in comp.lang.javas cript Thomas
'PointedEars' Lahn <PointedEars@we b.de>
<46D2CC54.20706 04@PointedEars. dewrote:

>| Jeff North wrote:
>| [...] "dhtmlkitchen@g mail.com" [...] wrote:
>| >| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
>| >| widget?
>| >
>| http://docs.jquery.com/Using_jQuery_...ther_Libraries
>| The jQuery library, and virtually all of its plugins are constrained
>| within the jQuery namespace. As a general rule, "global" objects are
>| stored inside the jQuery namespace as well, so you shouldn't get a
>| clash between jQuery and any other library (like Prototype, MooTools,
>| or YUI).
>|
>| However, that is completely ignoring the fact that ECMAScript 3
>| implementations have no concept of a namespace, and that any
>| user-defined object or property may be overwritten at any time.

I think that you are completely ignoring the fact that the people at
jQuery weren't using namespace in the context of the ECMAScript (non)
definition.

>| Please trim your quotes.

....and get abused for misquoting or trimming too much?

>| PointedEars

-- -------------------------------------------------------------
jnorthau@yourpa ntsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------

[Matt Kruse]

Re: third-party libraries

On Aug 27, 9:35 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

It is neither generalised not ironic. It is a general statement that is
trivially true. It is also an important statement because there are
browser scripting problems that are insoluble (or can never be complexly
solved, or for which the solution is non-viable (mostly fare too big and
slow to use) generally, but can be solved in the majority of known
contexts because in those contexts sufficient aspects of the general
problem can be observed to be absent that what remains can be handled.

One common argument in favor of some browser sniffing is that a
generalized test to check for a browser quirk or misbehavior may be
quite long and complex, even though the problem is known to only exist
in a single browser or a single environment. Why write extensive extra
code to solve the general case when it's never been shown that there
is a problem outside of the very specific case?

Relying on browser sniffing and some object detection would surely be
shorter, faster, and just as compatible. Although it wouldn't cover
the case where some other browser develops the same problem, why worry
about a situation that can be demonstrated as not existing? If it pops
up in the future, why not generalize it at that point if necessary?

Matt Kruse

[Richard Cornford]

Re: third-party libraries

"Matt Kruse" <matt@mattkruse .comwrote:

On Aug 27, 9:35 am, Richard Cornford wrote:

>It is neither generalised not ironic. It is a general statement
>that is trivially true. It is also an important statement because
>there are browser scripting problems that are insoluble (or can
>never be complexly solved, or for which the solution is non-viable

^^^^^^^^^
Should have been "completely ".

>(mostly fare too big and slow to use) generally, but can

^^^
"far"

>be solved in the majority of known contexts because in
>those contexts sufficient aspects of the general problem
>can be observed to be absent that what remains can be handled.

>
One common argument in favor of some browser sniffing is that a
generalized test to check for a browser quirk or misbehavior
may be quite long and complex,

Aren't we a few posts down stream of code showing a browser sniffing
based test that is more complex than it could have been precisely
because of the browser sniffing (that is, a test where the subject
should have been the type of the Node, not the type of the Node plus
whether the browser was Safari)?

It also would not be much of an argument in the face of examples of
browser sniffing code that includes and executes 500+ lines just for the
browser sniffing, and regardless of whether or not the results are ever
used.

Still, to date you are the only person who has mentions this "common
argument" to me. Obviously I must be not taking part in enough browser
sniffing and feature testing related debates.

even though the problem is known to only exist
in a single browser or a single environment.

How would it be "known" that the problem only existed on a single
browser? Logically haven't you got to positively verify that the problem
does not exist on _every_ other browser in existence before you can know
that? Given that the people who put most effort into collection web
browsers are the least convinced that it is possible to possess all web
browsers isn't that supposed 'knowledge' practically unachievable?

Without that knowledge you are in the area of surmise and assumptions.

Why write extensive extra code to solve the general
case when it's never been shown that there
is a problem outside of the very specific case?

You don't write browser sniffing code because it is imposable to write
such code so that it will accurately identify browsers or their
versions. Thus you could not know that there was a certain relationship
between the results of such tests and the condition that was the
purported reason for the test. While the principle of feature detection
that a good feature detection test tests a condition that has a
one-to-one relationship with whatever it is that the test is supposed to
determine, if achievable, guarantees the relationship of the test with
the need for a test.

Relying on browser sniffing and some object detection would
surely be shorter, faster, and just as compatible.

In some cases shorter and faster (but not in all cases by a very long
way), but just not (and never) reliable. Remember that browser sniffing
is predicated on treating something that is not supposed to be treated
as a source of information is if it was a source of information.
Reliable outcomes cannot be achieved in that way.

Although it wouldn't cover the case where some other browser
develops the same problem,

Or already had the same problem but had gone unnoticed by whoever
designed the browser sniffing code.

why worry about a situation that
can be demonstrated as not existing?

How were you planning on "demonstrat ing" that no unknown or unrecognised
browser has the issue in question? Trying a test-case on all browsers
may represent such a demonstration, if achievable at all, but it is
hardly realistic to propose such an extreme action as a prerequisite of
something that is purported to be "shorter and faster".

If it pops up in the future, why not generalize it
at that point if necessary?

Isn't the cost of ongoing maintenance to be considered? Haven't there
been enough examples of browser sniffing needing to be modified at each
release of a new browser, and of positively silly outcomes following
from author's falling to keep up with developments in browsers? How can
it ever make sense to be telling someone using the last version of a web
browser that they need to be upgrading to a newer version?

One of the greatest practical advantages of feature detection tests is
that if you get the test right it keeps on being the right test
regardless if whether the issue being tested for is fixed, crops up
somewhere else, or is accidentally re-introduced.

Richard.

[Thomas 'PointedEars' Lahn]

Re: third-party libraries

Jeff North wrote:

On Mon, 27 Aug 2007 15:06:28 +0200, in comp.lang.javas cript Thomas
'PointedEars' Lahn <PointedEars@we b.de>
<46D2CC54.20706 04@PointedEars. dewrote:

There is no need to replicate this much header information in the message
body. The attribution should be short so that it fulfills its purpose as
to indicate merely who wrote what of the quoted text.

>| Jeff North wrote:
>| [...] "dhtmlkitchen@g mail.com" [...] wrote:
>| >| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
>| >| widget?
>| >
>| http://docs.jquery.com/Using_jQuery_...ther_Libraries
>| The jQuery library, and virtually all of its plugins are constrained
>| within the jQuery namespace. As a general rule, "global" objects are
>| stored inside the jQuery namespace as well, so you shouldn't get a
>| clash between jQuery and any other library (like Prototype, MooTools,
>| or YUI).
>|
>| However, that is completely ignoring the fact that ECMAScript 3
>| implementations have no concept of a namespace, and that any
>| user-defined object or property may be overwritten at any time.

>
I think that you are completely ignoring the fact that the people at
jQuery weren't using namespace in the context of the ECMAScript (non)
definition.

You are missing the point. The concept of a namespace implies that
something defined in that namespace cannot be overwritten by other
pieces of code because of that namespace. Using an object as a
pseudo-namespace certainly can help to avoid conflicts when using
different libraries, but anything more is just a wild guess that
can not be backed up by features of the used programming language.

>| Please trim your quotes.

>
...and get abused for misquoting or trimming too much?

Abused? Not by me, or only by trolls, if you use common sense.

http://www.jibbering.com/faq/faq_notes/clj_posts.html

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$8 300dec7@news.de mon.co.uk>

[Matt Kruse]

Re: third-party libraries

On Aug 27, 1:44 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

Aren't we a few posts down stream of code showing a browser sniffing
based test that is more complex than it could have been precisely
because of the browser sniffing

It appears so, but I think we're now discussing the broader issue, not
that specific case.

It also would not be much of an argument in the face of examples of
browser sniffing code that includes and executes 500+ lines just for the
browser sniffing, and regardless of whether or not the results are ever
used.

True, such code exists, but it's also not relevant to jQuery.

Still, to date you are the only person who has mentions this "common
argument" to me. Obviously I must be not taking part in enough browser
sniffing and feature testing related debates.

A few url's:

http://ejohn.org/blog/future-proofing-javascript-libraries/

http://andrewdupont.net/2007/04/04/browser-sniffing/

http://dev.opera.com/articles/view/using-capability-detection/

even though the problem is known to only exist
in a single browser or a single environment.

How would it be "known" that the problem only existed on a single
browser? Logically haven't you got to positively verify that the problem
does not exist on _every_ other browser in existence before you can know
that?

Perhaps if you are seeking logical perfection, yes. Practically,
perfection isn't required. Of all the browsers you claim exist, I'll
bet that I haven't seen hardly any of them visit the sites I care
about. Devoting effort and thought to a fringe user who might someday
visit my site with a browser I don't know about is not something I
really care that much about.

Without that knowledge you are in the area of surmise and assumptions.

Which may be a fine area to be in.

You don't write browser sniffing code because it is imposable to write
such code so that it will accurately identify browsers or their
versions.

And yet the code that exists seems to work just fine for every single
user I've ever cared about, without exception. Believe me, I
understand your theoretical/logical argument. If you're seeking
perfect logical consistency similar to a mathematical proof, you are
absolutely correct in your arguments. But sometimes "good enough"
really _is_ "good enough". Why kill yourself trying to create an
exhaustive and bullet-proof detection algorithm that may not even be
possible? You could instead solve the case for every known user and
every probable future user of your site with some simple code, and
leave open the possibility that a rare case may exist in the future
that may make you want to reconsider your code. Or download the latest
version of your library and find that 20 others have already
investigated the problem and fixed it for you.

Remember that browser sniffing
is predicated on treating something that is not supposed to be treated
as a source of information is if it was a source of information.

Again, perhaps technically true. But in reality, it is a source of
information. And it's correct for almost every single user with the
exception of some people who purposely try to provide inaccurate
information. Personally, I don't care about those people. That's not
perfect, but it sure is practical.

why worry about a situation that
can be demonstrated as not existing?

How were you planning on "demonstrat ing" that no unknown or unrecognised
browser has the issue in question?

You can't prove it conclusively. But, for example, I often code for
apps that support only IE or maybe IE/FF. I can demonstrate well that
there are no known issues outside of my supported browser environment.
And for my case, browser detection (when required) works flawlessly,
without exception.

One of the greatest practical advantages of feature detection tests is
that if you get the test right it keeps on being the right test
regardless if whether the issue being tested for is fixed, crops up
somewhere else, or is accidentally re-introduced.

I agree. And where practical, that approach is always preferred.

Matt Kruse

[Thomas 'PointedEars' Lahn]

Re: third-party libraries

Matt Kruse wrote:

On Aug 27, 9:38 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>>Needless to say, your opinion is in the minority, even among experts.

>Are we back to ad hominem again? You cannot even prove that, no matter your
>definition of "experts".

>
It's an obvious conclusion, IMO, if you just spend time reading the
web and following the advances in the javascript world.

You have allowed your reasoning to be influenced, if not controlled, by
emotion, so statements like the above have to appear to you as an obvious
conclusion. As long as you continue like this, you do not deserve to be
taken seriously anymore.

>But the library itself defines it, and it defines and uses more properties
>that begin with `$'.

>
Only as an alias for jQuery. [...]

No, there is a $this variable, and an $events and a $handle property. It
turns out that I have reviewed the source; obviously you have not. (What
would your "experts" say about people who state facts about something
and are defending it even if they do not even know about it to make such
statements? Don't answer.)


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Matt Kruse]

Re: third-party libraries

On Aug 27, 3:36 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

You have allowed your reasoning to be influenced, if not controlled, by
emotion, so statements like the above have to appear to you as an obvious
conclusion. As long as you continue like this, you do not deserve to be
taken seriously anymore.

Did you take me seriously to begin with? Do I care? :)

But the library itself defines it, and it defines and uses more properties
that begin with `$'.

Only as an alias for jQuery. [...]

No, there is a $this variable, and an $events and a $handle property. It
turns out that I have reviewed the source; obviously you have not.

Actually, I just misunderstood what you meant.

Matt Kruse

[Jeff North]

Re: third-party libraries

Well you might also let the people at Yahoo, Google et al know this
because they use the same terminology.

>| >| Please trim your quotes.

Post trimmed - happy now?
-- -------------------------------------------------------------
jnorthau@yourpa ntsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------