Javascript library development
Aaron Gray
browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like the
base level to pitch at.
Anyone add anything ?
Aaron
Peter Michaux
> From what I have been looking at for Javascript library development,
Are you going to be writing your own library?
> browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like the
> base level to pitch at.
Roughly yes. It depends on your targeted user base and the browsers
they are using. If it is for the general web vs for an intranet where
everyone is using a single browser.
> Anyone add anything ?
If you use feature detection and progressive enhancement your library
will fail gracefully in older browsers. It is a sustainable approach.
For example. navigator.userAgent should not appear in your library
code.
There is a lure that a single library can cover all possible
situations. That has never been shown to be true and if such a library
could be written it would be huge. Determining the position of an
element on the page is an example of a big problem.
Identify the requirements for you library and then either find or
write a library to suit that need.
Peter
Aaron Gray
news:a5793e40-958f-4d26...@t54g2000hsg.googlegroups.com...
> On Jul 11, 8:54 am, "Aaron Gray" <ang.use...@gmail.com> wrote:
>> From what I have been looking at for Javascript library development,
>
> Are you going to be writing your own library?
Yes.
>> browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like
>> the
>> base level to pitch at.
>
> Roughly yes. It depends on your targeted user base and the browsers
> they are using. If it is for the general web vs for an intranet where
> everyone is using a single browser.
Yes, it looks like the cutoff point.
There's the W3C DOM standard introduction and things like
document.documentElement which I have tried to address.
>> Anyone add anything ?
>
> If you use feature detection and progressive enhancement your library
> will fail gracefully in older browsers. It is a sustainable approach.
> For example. navigator.userAgent should not appear in your library
> code.
Yes, other than for error reporting :)
> There is a lure that a single library can cover all possible
> situations. That has never been shown to be true and if such a library
> could be written it would be huge.
Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
very expensive for commercial usage. I am looking at creating a frame work
with widget structure a few basic widgets and publish it under the LGPL,
then hopefully if it is anygood others will contribute, thats the idea
anyway.
> Determining the position of an
> element on the page is an example of a big problem.
Right. I try to use events attached to elements where ever possible.
> Identify the requirements for you library and then either find or
> write a library to suit that need.
ExtJS is the only contender but as I said it is prohibitorly expensive for
small scale commercial usage.
Aaron
Peter Michaux
> "Peter Michaux" <petermich...@gmail.com> wrote in message
> news:a5793e40-958f-4d26...@t54g2000hsg.googlegroups.com...
> > On Jul 11, 8:54 am, "Aaron Gray" <ang.use...@gmail.com> wrote:
> > > From what I have been looking at for Javascript library development,
>
> > Are you going to be writing your own library?
>
> Yes.
With all due respect, if you are new enough to browser scripting to be
asking the questions that you are, I suggest you write a few libraries
and really explore the JavaScript language and the browser runtimes
before you release a library to the world. By explore, I mean spend at
least a year reading other libraries, writing example libraries,
reading articles by programmers like Richard Cornford and Douglas
Crockford. Crockford's "JavaScript: the good parts" book is really the
only book on JavaScript that attempts to explore the lambda-nature of
JavaScript and exploit it for maximum gain. Books about Lisp and
Scheme (especially "Structure and Interpretation of Computer Programs"
by Abelson and Sussman) which are lambda languages, are generally far
higher quality than JavaScript books but the ideas translate to
JavaScript quite readily. Quality books on browser scripting are at
least hard to find.
On the web it is already possible to download JavaScript libraries for
browser scripting with APIs that were published and subsequently
"fixed" by people with little experience writing browser scripts and
who seemed to carry a lot of baggage and/or preconceived ideas about
how to program from whatever language they wrote in before they
arrived in JavaScript. (Usually they programmed in a class-based, non-
lambda language which is almost polar opposite to JavaScript.) These
efforts have resulted in libraries that don't maximize use of the
things JavaScript does well, don't fully acknowledge the realities of
the browser environment and use feature detection to deal with them,
assume they know the right way to do things and end up with an API
that is really difficult to make work with the techniques they would
choose with more experience.
> > If you use feature detection and progressive enhancement your library
> > will fail gracefully in older browsers. It is a sustainable approach.
> > For example. navigator.userAgent should not appear in your library
> > code.
>
> Yes, other than for error reporting :)
What kind of error reporting?
> > There is a lure that a single library can cover all possible
> > situations. That has never been shown to be true and if such a library
> > could be written it would be huge.
>
> Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
> very expensive for commercial usage. I am looking at creating a frame work
> with widget structure a few basic widgets and publish it under the LGPL,
> then hopefully if it is anygood others will contribute, thats the idea
> anyway.
>
> > Determining the position of an
> > element on the page is an example of a big problem.
>
> Right. I try to use events attached to elements where ever possible.
Event target resolution is not what I was referring to in this case.
That would be a really crazy way to identify what was clicked, for
example.
> > Identify the requirements for you library and then either find or
> > write a library to suit that need.
>
> ExtJS is the only contender
Why? All the regulars on this group write browser scripts and I think
none uses ExtJS.
> but as I said it is prohibitorly expensive for
> small scale commercial usage.
If the quality of ExtJS is considered acceptable (which would likely
be highly debated on this newsgroup) then why not fork the last
version of ExtJS that was free for commercial use?
Peter
Aaron Gray
> On Jul 12, 12:02 pm, "Aaron Gray" <ang.use...@gmail.com> wrote:
>> "Peter Michaux" <petermich...@gmail.com> wrote in message
>> news:a5793e40-958f-4d26...@t54g2000hsg.googlegroups.com...
>> > On Jul 11, 8:54 am, "Aaron Gray" <ang.use...@gmail.com> wrote:
>> > > From what I have been looking at for Javascript library development,
>>
>> > Are you going to be writing your own library?
>>
>> Yes.
>
> With all due respect, if you are new enough to browser scripting to be
> asking the questions that you are, I suggest you write a few libraries
> and really explore the JavaScript language and the browser runtimes
> before you release a library to the world. By explore, I mean spend at
> least a year reading other libraries, writing example libraries,
> reading articles by programmers like Richard Cornford and Douglas
> Crockford. Crockford's "JavaScript: the good parts" book is really the
> only book on JavaScript that attempts to explore the lambda-nature of
> JavaScript and exploit it for maximum gain. Books about Lisp and
> Scheme (especially "Structure and Interpretation of Computer Programs"
> by Abelson and Sussman) which are lambda languages, are generally far
> higher quality than JavaScript books but the ideas translate to
> JavaScript quite readily. Quality books on browser scripting are at
> least hard to find.
Try John Resig's book and site.
> On the web it is already possible to download JavaScript libraries for
> browser scripting with APIs that were published and subsequently
> "fixed" by people with little experience writing browser scripts and
> who seemed to carry a lot of baggage and/or preconceived ideas about
> how to program from whatever language they wrote in before they
> arrived in JavaScript. (Usually they programmed in a class-based, non-
> lambda language which is almost polar opposite to JavaScript.) These
> efforts have resulted in libraries that don't maximize use of the
> things JavaScript does well, don't fully acknowledge the realities of
> the browser environment and use feature detection to deal with them,
> assume they know the right way to do things and end up with an API
> that is really difficult to make work with the techniques they would
> choose with more experience.
Yep, I do agree to some degree.
>> > If you use feature detection and progressive enhancement your library
>> > will fail gracefully in older browsers. It is a sustainable approach.
>> > For example. navigator.userAgent should not appear in your library
>> > code.
>>
>> Yes, other than for error reporting :)
>
> What kind of error reporting?
If an error occurs in the Library then it uses AJAX to send home an error
report with as much information as it can gather, this is then entered into
a MySQL database app and a report produced and sent by email to me and maybe
me and the user of the library.
>> > There is a lure that a single library can cover all possible
>> > situations. That has never been shown to be true and if such a library
>> > could be written it would be huge.
>>
>> Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
>> very expensive for commercial usage. I am looking at creating a frame
>> work
>> with widget structure a few basic widgets and publish it under the LGPL,
>> then hopefully if it is anygood others will contribute, thats the idea
>> anyway.
>>
>> > Determining the position of an
>> > element on the page is an example of a big problem.
>>
>> Right. I try to use events attached to elements where ever possible.
>
> Event target resolution is not what I was referring to in this case.
> That would be a really crazy way to identify what was clicked, for
> example.
For most click events the object that is clicked on is where the click event
is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
me to other uses if there are some :)
>
>> > Identify the requirements for you library and then either find or
>> > write a library to suit that need.
>>
>> ExtJS is the only contender
>
> Why? All the regulars on this group write browser scripts and I think
> none uses ExtJS.
Then where are the general UI libraries that are any good. Bespoke code is
good but it is not generally complatible with other bespoke code and making
libraries is what is interesting to me.
Laying down the right framework is crucial.
>> but as I said it is prohibitorly expensive for
>> small scale commercial usage.
>
> If the quality of ExtJS is considered acceptable (which would likely
> be highly debated on this newsgroup) then why not fork the last
> version of ExtJS that was free for commercial use?
I have looked at ExtJS's code and yes its not brilliant if you look at the
DOM generated there ar unclosed <div>'s and <ul>'s in the tree control,
unless this is due to a bug in FireBug and DebugBar.
Yahoo's UI is even less self integrated.
Where are the good libraries ? I am not into making just another wheel, I
want a good wheel.
Peter, most of the time I post to newsgroups I am just trying to get
pragmatics of an issue which UseNet is usually great for.
Basically I have been programming in Javascript on and off for over three
years now. And I want my own framework and UI library that works hopefully
on any Javascript 1.6 / ECMA3 compilant browser, hence the questions.
Regards,
Aaron
Gregor Kofler
>> Quality books on browser scripting are at
>> least hard to find.
>
> Try John Resig's book and site.
Er... why? Most regulars here - including Peter - have a much better
understanding of JS than the "JavaScript Ninja".
As stated: Crockford's "JS the Good Parts" is definitely worth reading.
> For most click events the object that is clicked on is where the click event
> is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
> me to other uses if there are some :)
Events bubble. Instead of attaching a listener to every node of my XHR
tree widget, one attached to the container of the tree does the job. The
clicked element is identified via its class name.
>>> ExtJS is the only contender
>> Why? All the regulars on this group write browser scripts and I think
>> none uses ExtJS.
>
> Then where are the general UI libraries that are any good.
Because there are no good "general UI library" - and perhaps never will
be. It's this "general" that causes so much trouble.
> Where are the good libraries ? I am not into making just another wheel, I
> want a good wheel.
Either write your own (that's the most likely suggestion you gonna get
here), or pick whatever you want and live with the shortcomings.
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
Aaron Gray
news:Jxbek.81$1l4...@nntpserver.swip.net...
> Aaron Gray meinte:
>
>>> Quality books on browser scripting are at
>>> least hard to find.
>>
>> Try John Resig's book and site.
>
> Er... why? Most regulars here - including Peter - have a much better
> understanding of JS than the "JavaScript Ninja".
Right I have just looked at the contents on Amazon.
> As stated: Crockford's "JS the Good Parts" is definitely worth reading.
Right.
>> For most click events the object that is clicked on is where the click
>> event is needed. Its only DnD that needs anything smarter AFAICS. Please
>> enlighten me to other uses if there are some :)
>
> Events bubble. Instead of attaching a listener to every node of my XHR
> tree widget, one attached to the container of the tree does the job. The
> clicked element is identified via its class name.
>
>>>> ExtJS is the only contender
>>> Why? All the regulars on this group write browser scripts and I think
>>> none uses ExtJS.
>>
>> Then where are the general UI libraries that are any good.
>
> Because there are no good "general UI library" - and perhaps never will
> be. It's this "general" that causes so much trouble.
I agree, but am taking up the chalenge to try to make one, may probably fail
but then at least I have tried.
>> Where are the good libraries ? I am not into making just another wheel, I
>> want a good wheel.
>
> Either write your own (that's the most likely suggestion you gonna get
> here), or pick whatever you want and live with the shortcomings.
Writing my own is the best option, then atleast if I want to modify it I
know how rather than maybe using a hodgepodge of the others and ending in an
entropic state.
Aaron
Richard Cornford
> Peter Michaux wrote:
>> On Jul 12, 12:02 pm, Aaron Gray wrote:
>>> Peter Michaux wrote:
<snip>
>>>> Are you going to be writing your own library?
>>>
>>> Yes.
>>
>> With all due respect, if you are new enough to browser scripting
>> to be asking the questions that you are, I suggest you write a
>> few libraries and really explore the JavaScript language and the
>> browser runtimes before you release a library to the world.
>> Books about Lisp and Scheme (especially "Structure and
>> Interpretation of Computer Programs" by Abelson and Sussman)
>> which are lambda languages, are generally far higher quality
>> than JavaScript books but the ideas translate to JavaScript
>> quite readily. Quality books on browser scripting are at
>> least hard to find.
>
> Try John Resig's book and site.
That "John Resig's book" would be "Pro JavaScript Techniques"? The book
that contains:-
"Since valid HTML is simply a subset of XML, having an efficient way to
parse and browser DOM documents is an absolutely essential for making
JavaScript development easier."
"Even if you're not completely familiar with XML, you will get great
satisfaction knowing that all HTML documents (which are, in the eyes of
the browser, XML documents) have a DOM representation that is ready to
use."
"Since the use of JavaScript in nonbrowser settings (e.g., server-side
JavaScript) is still rather experimental, the feature set of JavaScript
is still very browser-centric. Thus, the features available in
JavaScript are very closely tied to how browsers evolve and which
features they (or their users) deem as the most important."
"Additionally, an object can contain a set of properties, all of which
are simply references to other objects (such as strings, numbers,
arrays, etc.)."
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string."
"The this variable will always refer to the object that the code is
currently inside of."
"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."
"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined"
"Compression should be used as the final step, just before putting your
code into production, as your code will frequently become obfuscated
beyond recognition."
"This particular naming convention arose due to the fact that words such
as class, for, float, and text are all reserved words in JavaScript."
- and many other examples of technical fallacies, misconceptions and bad
practices.
Peter's point is, in effect, that if you don't know enough about
javascript and browser scripting to recognise a bad book when you see
one then maybe you should be a bit circumspect about rushing into
designing a library and dumping it on a community who have less
understanding of what they are doing than you do.
<snip>
> Basically I have been programming in Javascript on and off for
> over three years now. And I want my own framework and UI
> library that works hopefully on any Javascript 1.6 / ECMA3
> compilant browser, hence the questions.
Well, it will make a change for IceBrowser, Konqueror and NetFront to
get a look-in.
Richard.
Aaron Gray
news:g5bkab$roh$1$8300...@news.demon.co.uk...
> Aaron Gray wrote:
>> Peter Michaux wrote:
>>> On Jul 12, 12:02 pm, Aaron Gray wrote:
>>>> Peter Michaux wrote:
> <snip>
I thought he looked a bit young :)
You typed in all that ?
Have not read the book just read his web site which on the whole is pritty
good.
Yeah, you only have to look at the second hand price of the "new"ish book on
Amazon.
Oh well its probably okay for some people. I will probably still buy the
book just to see if there are some gems in it, then pass it on as a hand me
down if I don't then still want to keep it.
So its back to Douglas then, there's some goodies from him on Yahoo theatre
:-
http://developer.yahoo.com/yui/theater/
> Peter's point is, in effect, that if you don't know enough about
> javascript and browser scripting to recognise a bad book when you see one
> then maybe you should be a bit circumspect about rushing into designing a
> library and dumping it on a community who have less understanding of what
> they are doing than you do.
Javascript is a real evolving thing, I have been learning it and relearning
it looking ahead at Javascript 2.0 and getting a good overview of the lay of
the land.
> <snip>
>> Basically I have been programming in Javascript on and off for
>> over three years now. And I want my own framework and UI
>> library that works hopefully on any Javascript 1.6 / ECMA3
>> compilant browser, hence the questions.
Sorry that should be Javascript 1.5.
> Well, it will make a change for IceBrowser, Konqueror and NetFront to get
> a look-in.
I want to write the foundations to include as many browsers as possible from
a reasonable baseline, thats the plan anyway if it is possible then its
worth doing.
I am basically putting together a base level "legacy" support library, and
do a test set for it so that it can be tested on a range of browsers.
To be clever but not too clever with the level of Javascript coding is the
name of the game, some of the newer stuff is just too clever for its own
good, substituting efficiency and readability for technical prowesk.
Thanks Richard, some of those quotes were quite funny :)
Aaron
Richard Cornford
> Richard Cornford wrote:
>> Aaron Gray wrote:
>>> Peter Michaux wrote:
>>>> On Jul 12, 12:02 pm, Aaron Gray wrote:
>>>>> Peter Michaux wrote:
>> <snip>
>>> Try John Resig's book and site.
>>
>> That "John Resig's book" would be "Pro JavaScript Techniques"?
>> The book that contains:-
>> "This particular naming convention arose due to the fact that
>> words such as class, for, float, and text are all reserved words
>> in JavaScript."
>>
>> - and many other examples of technical fallacies, misconceptions
>> and bad practices.
>
> I thought he looked a bit young :)
Youth would not, it itself, be a barrier to understanding javascript.
ES3 is not that complex else it would not be possible for its
specification to be just 170 odd page (with 10% of that entirely devoted
to regular expressions).
> You typed in all that ?
No, I copied it from a list I have in a document. Though I did type the
list originally so I cannot promise that it is typo free. I used them as
humorous signatures for a month or so (john Resig didn't see the joke),
but have stopped now. The fear was express that my quoting them might be
taken as an endorsement.
> Have not read the book just read his web site which on the whole
> is pritty good.
YMMV
> Yeah, you only have to look at the second hand price of the
> "new"ish book on Amazon.
Low is it?
<snip>
> I want to write the foundations to include as many browsers as
> possible from a reasonable baseline, thats the plan anyway if
> it is possible then its worth doing.
I don't think "possible" == "worth doing" holds.
> I am basically putting together a base level "legacy" support
> library, and do a test set for it so that it can be tested on
> a range of browsers.
>
> To be clever but not too clever with the level of Javascript
> coding is the name of the game, some of the newer stuff is
> just too clever for its own good, substituting efficiency
> and readability for technical prowesk.
Yes, the last couple of years have seen the arrival of "do it this way
because it is cool". Talking design to people who take that attitude is
a bit like beating your head against a wall. (What is the best part of
beating your head against a wall? - Stopping.)
> Thanks Richard, some of those quotes were quite funny :)
I thought so. (That or they'd make you cry.)
Richard.
Peter Michaux
[snip]
> If an error occurs in the Library then it uses AJAX to send home an error
> report with as much information as it can gather, this is then entered into
> a MySQL database app and a report produced and sent by email to me and maybe
> me and the user of the library.
This is a nice idea but don't rely on the navigator.userAgent string
completely. The message the browser sends to the server could also
include the results of your feature tests. Then you could determine if
the navigator.userAgent correlates to the feature test results. Even
then you might have trouble. Just for IE6 there are many different
configurations and effectively IE6 could be seen as at least tens of
different browsers depending on the operating system configuration,
security options in the browser, etc.
Probably best to send this message with something very low tech like
creating an image element and setting the src property. Using
XMLHttpRequest for this would likely disable many of the browsers from
which you would like to receive messages from even being able to send
the message. In fact perhaps you'd want to try sending the message a
few different ways to make sure the message got through.
> For most click events the object that is clicked on is where the click event
> is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
> me to other uses if there are some :)
There are many other situations where event delegation could be handy.
If you have a list and you are adding and removing elements, it is
simpler if the list is listening for events rather than having to add
listeners to each element as it is inserted.
> >> > Identify the requirements for you library and then either find or
> >> > write a library to suit that need.
>
> >> ExtJS is the only contender
>
> > Why? All the regulars on this group write browser scripts and I think
> > none uses ExtJS.
>
> Then where are the general UI libraries that are any good. Bespoke code is
> good but it is not generally complatible with other bespoke code and making
> libraries is what is interesting to me.
>
> Laying down the right framework is crucial.
For a foundation, I'd suggest starting with a multi-browser event
library. That contains plenty of browser bugs and you will need to
make decisions about how to handle the various problems. For example,
in versions of Safari up to something like version 2.0.2, there was a
bug where prevent default didn't work for click and double click
events when the handler was added with addEventHandler. If the handler
is added by setting the onclick property of the element then prevent
default does work. As far as I know there is no feature test to detect
this issue. However these versions of Safari are getting old. What is
the right thing to do? The event library problem alone allows for very
rich exploration into the building of a multi-browser library. It has
been for me anyway. Building a solution entails feature detection
techniques, realizing "general" is a problem as Gregor rightly notes,
API design, knowing how to build a small solution with the JavaScript
language, etc.
> >> but as I said it is prohibitorly expensive for
> >> small scale commercial usage.
>
> > If the quality of ExtJS is considered acceptable (which would likely
> > be highly debated on this newsgroup) then why not fork the last
> > version of ExtJS that was free for commercial use?
>
> I have looked at ExtJS's code and yes its not brilliant if you look at the
> DOM generated there ar unclosed <div>'s and <ul>'s in the tree control,
> unless this is due to a bug in FireBug and DebugBar.
>
> Yahoo's UI is even less self integrated.
>
> Where are the good libraries?
They seem to be hard to find.
> I am not into making just another wheel, I
> want a good wheel.
The mainstream libraries are certainly not perfectly round wheels. So
if you need a round one you may have to build your own. First you need
to decide the requirements for your library.
> Peter, most of the time I post to newsgroups I am just trying to get
> pragmatics of an issue which UseNet is usually great for.
>
> Basically I have been programming in Javascript on and off for over three
> years now. And I want my own framework and UI library that works hopefully
> on any Javascript 1.6 / ECMA3 compilant browser, hence the questions.
I think learning as much as you can about feature testing techniques
is the most productive way to start. There is an article in the
group's FAQ notes which is a probably a very good place to start.
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html
Peter
Gregor Kofler
> "Gregor Kofler" <use...@gregorkofler.at> wrote in message
> news:Jxbek.81$1l4...@nntpserver.swip.net...
>> Because there are no good "general UI library" - and perhaps never will
>> be. It's this "general" that causes so much trouble.
>
> I agree, but am taking up the chalenge to try to make one, may probably fail
> but then at least I have tried.
My "core library" is about 15k: some DOM functions, event handling, some
small prototype extensions. If I need XHR the according library eats up
another 8-9k, most of it for Douglas' JSON functions. Another small
library does drag and drop (5k).
On top of those small scripts I write my widgets. Works for me.
Jorge
wrote:
> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
> that contains:-
> "When performing string concatenation the result is always a new string
> object rather than a modified version of the original string."
javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--> object, false, string.
javascript:a= "Hola";alert(typeof a);alert(a === (a+=
""));alert(typeof a);
--> string, true, string.
--Jorge.
Thomas 'PointedEars' Lahn
> On Jul 11, 8:54 am, "Aaron Gray" <ang.use...@gmail.com> wrote:
>> browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks
>> like the base level to pitch at.
>
> Roughly yes. It depends on your targeted user base and the browsers they
> are using. If it is for the general web vs for an intranet where
> everyone is using a single browser.
This should be understood as an AND-connected condition about the truth of
the statement. An intranet does _not_ mean everybody using it is using the
same user agent. And even if that applies *now*, it is very likely _not_ to
be true in the foreseeable future. Think about employees using mobile
devices like iPhone, for example.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Thomas 'PointedEars' Lahn
> "Richard Cornford" wrote:
>> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
>> that contains:-
>> (...)
>> "When performing string concatenation the result is always a new string
>> object rather than a modified version of the original string."
>
> javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
> ""));alert(typeof a);
> --> object, false, string.
>
> javascript:a= "Hola";alert(typeof a);alert(a === (a+=
> ""));alert(typeof a);
> --> string, true, string.
What exactly is the point you are trying to make here?
( ) Your confirming that John Resig does not know what he is writing about.
( ) Your not understanding what a String object is.
(It is a radio button group. Choose one.)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Jorge
wrote:
> Jorge wrote:
> > "Richard Cornford" wrote:
> >> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
> >> that contains:-
> >> (...)
> >> "When performing string concatenation the result is always a new string
> >> object rather than a modified version of the original string."
>
> > javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
> > ""));alert(typeof a);
> > --> object, false, string.
>
> > javascript:a= "Hola";alert(typeof a);alert(a === (a+=
> > ""));alert(typeof a);
> > --> string, true, string.
>
> What exactly is the point you are trying to make here?
>
> ( ) Your confirming that John Resig does not know what he is writing about.
> ( ) Your not understanding what a String object is.
>
> (It is a radio button group. Choose one.)
>
(·) Your not understanding what a String object is.
javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
+= ""));
--> object, true, false, string, object, true.
--Jorge.
Gregor Kofler
> javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
> a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
> += ""));
> --> object, true, false, string, object, true.
Still, what's your point? Everything works as expected.
"String objects are created by calling the constructor new String(). The
String object wraps Javascript's string primitive data type with the
methods described below. The global function String() can also be called
without new in front to create a primitive string. String literals in
JavaScript are primitive strings.
Because Javascript automatically converts between string primitives and
String objects, you can call any of the methods of the String object on
a string primitive. JavaScript automatically converts the string
primitive to a temporary String object, calls the method, then discards
the temporary String object." [1]
Gregor
[1]
<http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:String>
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Jorge wrote:
>>> "Richard Cornford" wrote:
>>>> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
>>>> that contains:-
>>>> (...)
>>>> "When performing string concatenation the result is always a new string
>>>> object rather than a modified version of the original string."
>>> javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
>>> ""));alert(typeof a);
>>> --> object, false, string.
>>> javascript:a= "Hola";alert(typeof a);alert(a === (a+=
>>> ""));alert(typeof a);
>>> --> string, true, string.
>> What exactly is the point you are trying to make here?
>>
>> ( ) Your confirming that John Resig does not know what he is writing about.
>> ( ) Your not understanding what a String object is.
>>
>> (It is a radio button group. Choose one.)
>
> (·) Your not understanding what a String object is.
I see.
> javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
> a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
> += ""));
> --> object, true, false, string, object, true.
You have not named the implementation that you have tested with. However,
it works there as specified. Yet you missed the point:
"foo" is a primitive string value. new String("foo"), on the other hand, is
a reference to a newly created String object (which is rather bloated, in
comparison). While the string concatenation operation, be it `+' or `+=',
works for both values as operands (same "type" and mixed), its result is
(unsurprisingly) always a primitive string value, _not_ (a reference to) a
String object (as e.g. the `typeof' operation shows when applied to it).
IOW, John Resig does not know what he is writing about (there). Hopefully,
you will begin to as of now.
HTH
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>
Jorge
> Jorge meinte:
>
> > javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
> > a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
> > += ""));
> > --> object, true, false, string, object, true.
>
> Still, what's your point?
>
That yes, that string concatenation (even when fed with string
object(s)) yields string primitive values not string objects.
Try with "string".concat("string") and ["string"].join("string"), and
the results are the same :
javascript:alert(typeof (new String("Hola")).concat(""));
--> string.
javascript:alert(typeof [new String("Hola")].join(""));
--> string.
Still, Resig is right in the sense that a there's no way to modify a
string object. Or not ?
--Jorge.
Peter Michaux
> On Jul 14, 10:07 am, Gregor Kofler <use...@gregorkofler.at> wrote:
>
> > Jorge meinte:
>
> > > javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
> > > a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
> > > += ""));
> > > --> object, true, false, string, object, true.
>
> > Still, what's your point?
>
> That yes, that string concatenation (even when fed with string
> object(s)) yields string primitive values not string objects.
>
> Try with "string".concat("string") and ["string"].join("string"), and
> the results are the same :
>
> javascript:alert(typeof (new String("Hola")).concat(""));
> --> string.
>
> javascript:alert(typeof [new String("Hola")].join(""));
> --> string.
Just out of curiosity, since you are using the javascript protocol for
testing, do you know about the console in the Firebug extension for
Firefox?
> Still, Resig is right in the sense that a there's no way to modify a
> string object. Or not ?
You can modify a String object at least in the sense you can add
properties to it.
var s = new String("Hola");
alert(s.doAlert) ; undefined
s.doAlert = function() {
alert(this);
};
alert(s.doAlert) ; function()...
s.doAlert() ; makes an alert "Hola"
Peter
Jorge
wrote:
>
> (...)
>
> ( ) Your not understanding what a String object is.
>
> (It is a radio button group. Choose one.)
>
>
> IOW, John Resig does not know what he is writing about (there).
> Hopefully, you will begin to as of now.
>
( ) You forgot to take today's medication.
( ) You ran out of pills.
(It is a radio button group. Choose one.)
:-)
Regards,
--Jorge.
Jorge
> On Jul 14, 10:27 am, Jorge <jo...@jorgechamorro.com> wrote:
>
>
>
>
>
> > On Jul 14, 10:07 am, Gregor Kofler <use...@gregorkofler.at> wrote:
>
> > > Jorge meinte:
>
> > > > javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
> > > > a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
> > > > += ""));
> > > > --> object, true, false, string, object, true.
>
> > > Still, what's your point?
>
> > That yes, that string concatenation (even when fed with string
> > object(s)) yields string primitive values not string objects.
>
> > Try with "string".concat("string") and ["string"].join("string"), and
> > the results are the same :
>
> > javascript:alert(typeof (new String("Hola")).concat(""));
> > --> string.
>
> > javascript:alert(typeof [new String("Hola")].join(""));
> > --> string.
>
> Just out of curiosity, since you are using the javascript protocol for
> testing, do you know about the console in the Firebug extension for
> Firefox?
>
> > Still, Resig is right in the sense that a there's no way to modify a
> > string object. Or not ?
>
> You can modify a String object at least in the sense you can add
> properties to it.
Ok. Let's say that "there's no way to change the string in a string
object". (?)
--Jorge.
Peter Michaux
> s.doAlert() ; makes an alert "Hola"
Oops. I've been programming more Lisp than JavaScript lately. Make
that ";" a "//".
Peter
Richard Cornford
> On Jul 14, 7:41 pm, Peter Michaux wrote:
>> On Jul 14, 10:27 am, Jorge wrote:
>>> On Jul 14, 10:07 am, Gregor Kofler wrote:
<snip>
>>> Still, Resig is right in the sense that a there's no way
>>> to modify a string object. Or not ?
It is certainly the case that the statement about concatenation would
not have had to be very different in its wording in order to have been a
true statement about javascript (unlike some of the others which are
just wrong in every single detail).
But the significant aspect of that quote is what is revealed by the
error that it does contain. You will notice that the participants in
this group cover pretty much the whole spectrum of javascript knowledge,
form total novices (usually in the role of people asking for help)
though to people who have learnt enough to see aspects of the language
that its authors have (or would prefer to have) forgotten. Participate
for long enough and patterns start to emerge in terms of misconceptions
about the langue, and how those misconceptions relate to an individuals
positions along the javascript learning curve.
Misconceptions about the distinction between primitive values and object
values are very common among beginners. And people who come to
javascript from Java (especially, but not exclusively) have a strong
tendency to assume that javascript strings will be string object (as
they are in Java). The implications of that misconception are not that
great, but it still should be corrected (and here it is corrected on a
fairly regular basis). (Someone here corrected that misconception for me
back in 2002).
There is another pattern to be observed here; that superficial success
(often in the form of first managing to create something that works in
more than two browsers) results in massive overconfidence. The belief
that you have cracked the problem, seen the truth, learnt everything of
importance and entered the inner circle. It is a dangerous phenomenon,
partly because it encourages people to go out and do things that may not
be such a good idea in retrospect, and partly because confidence that
you already know everything can be a huge barrier to learning more
(and/or recognising that you may be wrong).
It is sometimes necessary to slap someone pretty hard to get them out of
that state. The person here who did that to me back in 2002 probably did
me one of the biggest favours I have ever received, even if I could not
properly appreciate that at the time.
>> You can modify a String object at least in the sense you
>> can add properties to it.
>
> Ok. Let's say that "there's no way to change the string
> in a string object". (?)
That certainly should not be a point being made in relation to
concatenation operations because in concatenation any non-string
primitive operands are type-converted into string primitives.
The truth is that javascript has no operations that are capable of
changing the value of any of its 5 primitives types. In the absence of
an operation that could chagne a primitive value primitive values must
be unchangeable (at least from the perspective of anyone programming
javascript).
Richard.
Mike Duffy
$8300...@news.demon.co.uk:
> Jorge wrote:
>
> There is another pattern to be observed here; that superficial success
> (...) results in massive overconfidence. The belief
> that you have cracked the problem, seen the truth, learnt everything of
> importance and entered the inner circle. It is a dangerous phenomenon,
> partly because it encourages people to go out and do things that may not
> be such a good idea in retrospect, and partly because confidence that
> you already know everything can be a huge barrier to learning more
> (and/or recognising that you may be wrong).
This can be said about almost any discipline. It may be though, that
programming languages make the mistakes more obvious, much in the same way
that it is impossible to proof-read your own prose.
Also, when you only see the final product, it is not obvious how much time
was spent exploring dead-end paths. (Also called "hands-on" learning.)