Starting to Build a JavaScript Library

[dhtml]

Frustrated with every other Javascript framework, I have decided to
write something better.

I want a Javascript library that doesn't get in the way, is easily
extensible. Just some basic framework to build on for widgets.

The BAD things of other libraries:
* Weird "OOP"ish schemes
* oversimplified interface that does more things behind the scenes
* Kitchen Sink - too much bloat in the main library file; non-
cohesive.
* buggy, with superficial examples that they call "tests"
* non-modular design
* core library features are poor, inconsistent across browsers, and
buggy

And, to quote Brendan Eich:
Too many of the JS/DHTML toolkits have the "you must use our APIs for
everything, including how you manipulate strings" disease.

I know what I don't want.

Goals:
* Minimal Framework, mainly used for AOP and OOP functionality
* unit tested
* AOP Event System
* Namespacing
* Modularity, Cohesion, Packaging based on REP
* No browser detection

TBD:
* import() - dynamic script insertion? Dependency resolution?
* Building files to modules is easier to test, but feels weird

RIA development using javascript, I need widgets (Data Table, Rich
Editor). Widgets need: DOM adapter functions (style, position,
className), Event-based ajax (or "deferred" Async's), Form
serialization, Drag 'n Drop, Animation.
I
JavaScript lacks "import" and "extend" which are useful for widgets. I
use AOP cross cuts even more. I have not seen 1 library that gets
these things right. It is very important to get this part right.

The base component is APE.js ->
http://dhtmlkitchen.com/ape/src/APE.js

It is too early to be releasing the code, but I want to get some
feedback sooner rather than later. One pair of eyes on the code isn't
enough.

APE, by itself does nothing. I have some tests for what it does,
http://dhtmlkitchen.com/ape/test/tests/APE-test.html

[timothytoe]

It may be possible to improve the performance of your "extend" by
using Cornford's method in this thread:

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/fc74c84dfefe26a0/38e8a2d75e864536?lnk=gst&q=crockford#38e8a2d75e864536

[dhtml]

> http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...

Makes sense. Did that.

[Peter Michaux]

On Feb 16, 1:14 pm, dhtml <dhtmlkitc...@gmail.com> wrote:

> Frustrated with every other Javascript framework, I have decided to
> write something better.
>
> I want a Javascript library that doesn't get in the way, is easily
> extensible. Just some basic framework to build on for widgets.

You may like to look at some of this code

<URL: http://cljs.michaux.ca/>

> * import() - dynamic script insertion? Dependency resolution?

I don't think that level of complexity in production is a good idea.
Work harder in development and have better performance in production.

> * Building files to modules is easier to test, but feels weird

Why? Most programming environments require a build step.

I don't think the monolith style library is a good idea.

------------

You need a very clear idea of which browsers you are targeting or is
your code for the general web? Then you need a plan for feature
detection. David Mark has been going through his system with the group
for a few months now. I've summarized it as an article just yesterday

<URL: http://peter.michaux.ca/article/7146>

Peter

[Peter Michaux]

On Feb 16, 1:14 pm, dhtml <dhtmlkitc...@gmail.com> wrote:

> The base component is APE.js ->http://dhtmlkitchen.com/ape/src/APE.js

I don't think you need the namespace function. One namespace level *at
most* is sufficient. If you can't manage your namespace collisions in
a few thousand lines of code you have a big problem that needs to be
addressed. Emacs-lisp is all in one jumbo namespace and that is at
least many tens of thousands of lines that has survived decades.

Your extend function looks like something I thought was a good idea.
If you do keep it, your library shouldn't be dependent on it. In fact
your library should depend on itself as little as possible.

Peter

[Peter Michaux]

On Feb 16, 1:14 pm, dhtml <dhtmlkitc...@gmail.com> wrote:

String.prototype.normalize =

Really bad. This is a major problem with Prototype and has burned them
when a browser implements the very same function. If you are keen on
namespacing then you definitely shouldn't be playing with common
objects.

"Don't modify objects you don't own."

Do this...

function normalizeString(string) {}

Peter

[dhtml]

I've put a conditional check before each:

if(!String.prototype.trim)
String.prototype.trim = function(){...}

What is the disadvantage?

> Peter

[Joost Diepenmaat]

dhtml <dhtmlk...@gmail.com> writes:

> I've put a conditional check before each:
>
> if(!String.prototype.trim)
> String.prototype.trim = function(){...}
>
> What is the disadvantage?

The disadvantage is that *if* some browser implements
String.prototype.trim in some way that has different semantics it could
break the script.

Chances of that happening are probably higher than chances of a browser
implementing APE.trim() for instance.

Personally though, I would (and do) take that risk for *some*
functionality simply because it allows for a straight forward way to do
polymorphism (which may imply you shouldn't use it for functions that
have no real polymorphic uses).

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[dhtml]

On Feb 16, 2:27 pm, Peter Michaux <petermich...@gmail.com> wrote:

couldn't find a disadvantage.

I did some analysis and I was only using trim()/normalize() with my
className functions. I reduced this to one function, normalize, as
that's all I needed. So I have one fewer function call, I also have
normalize in the enclosing scope (closure), so it might be faster to
access (doesn't have to look up the prototype chain.

I wrote a test for my className functions:
http://dhtmlkitchen.com/ape/test/tests/dom/classname-f-test.html

The fully expanded, commented version of APE.js is down to 2.9k.

I'm happy with the change.

Garrett

[David Mark]

Something is very wrong with the style of that test page. I can't see
the leftmost edge (which makes it impossible to read the results of
the test) and there is a horizontal scrollbar in IE7.

[Lasse Reichstein Nielsen]

dhtml <dhtmlk...@gmail.com> writes:

> Frustrated with every other Javascript framework, I have decided to
> write something better.
>
> I want a Javascript library that doesn't get in the way, is easily
> extensible. Just some basic framework to build on for widgets.

Sounds like the goal of jQuery too. I would at least listen -
critically- to the author of that, to see what experience can
be reused.
http://www.youtube.com/watch?v=0LKDImgRfrg

I must say he sounds more reasonable in this talk than in Richard
Cornford's signatures.

/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.'

[dhtml]

On Feb 17, 5:24 am, Lasse Reichstein Nielsen <l...@hotpop.com> wrote:

> dhtml <dhtmlkitc...@gmail.com> writes:
> > Frustrated with every other Javascript framework, I have decided to
> > write something better.
>
> > I want a Javascript library that doesn't get in the way, is easily
> > extensible. Just some basic framework to build on for widgets.
>
> Sounds like the goal of jQuery too. I would at least listen -
> critically- to the author of that, to see what experience can
> be reused.
> http://www.youtube.com/watch?v=0LKDImgRfrg
>

I watched that before. I disagree with most of what he says, I think
it deserves at least one, if not two threads to go over. It's mostly
higher-level API design stuff. Though I do agree with some of it. It
gave me contrast to say: That's what I DON'T want to do.

API design deserves a thread to discuss all the namespacing, modifying
built-ins, one file vs build system.

Going back to my code sample. timothytoe suggested I reuse the
function. Since I'm working with an Object literal, I am considering
to make a function property. I don't like this property, but I can
reuse it in two functions.

fun : function(){},

Each call to newApply used create a function, then call extend, which
created another function. It's inefficient.

/**
* @param {Function} fun constructor to be invoked.
* @param {Array} args arguments to pass to the constructor.
*/
newApply : function(fun, args) {
var f = APE.fun;
f.prototype = fun.prototype;// Copy prototype.
f.prototype.constructor = f;

var i = new f;
fun.apply(i, args); // Apply the original constructor.
return i;
},

What do you think?

I could instead wrap the whole thing in a closure, just for the sake
of reusing fun.

Garrett

[Lasse Reichstein Nielsen]

dhtml <dhtmlk...@gmail.com> writes:

>
> /**
> * @param {Function} fun constructor to be invoked.
> * @param {Array} args arguments to pass to the constructor.
> */
> newApply : function(fun, args) {
> var f = APE.fun;

I wouldn't care about reuse here, unless performance is a problem
and the problem can be tracked to the creation of empty functions
here.
Readability-wise, I have to know here that APE.fun is an empty
function where it doesn't matter that I clobber its prototype.

> f.prototype = fun.prototype;// Copy prototype.
> f.prototype.constructor = f;

Why change the constructor property?

I would expect the effect of
newApply(fun,[arg1,arg2])
to be equivalent to
new fun(arg1, arg2)
and the latter inherits a prototype with .constructor == fun,
not APE.fun.

> var i = new f;

For readability, I would capitalize "f", and use a different variable
name than "i" (suggests a loop index), e.g., "o" or "newObject".

> fun.apply(i, args); // Apply the original constructor.
> return i;
> },
>
>
> What do you think?

Neat idea!

[dhtml]

On Feb 17, 10:17 pm, Lasse Reichstein Nielsen <l...@hotpop.com> wrote:
> dhtml <dhtmlkitc...@gmail.com> writes:
>

<snip>

> Why change the constructor property?
>
> I would expect the effect of
> newApply(fun,[arg1,arg2])
> to be equivalent to
> new fun(arg1, arg2)
> and the latter inherits a prototype with .constructor == fun,
> not APE.fun.
>

You're right.

> > var i = new f;
>
> For readability, I would capitalize "f", and use a different variable
> name than "i" (suggests a loop index), e.g., "o" or "newObject".
>
> > fun.apply(i, args); // Apply the original constructor.
> > return i;
> > },
>
> > What do you think?
>

You're right about the constructor prop. I'll change f to F. As for |
i|, well, I'll think about a better variable name. I was thinking
"instance", but just called it |i| for brevity.

Now I need a test to make sure the constructor property is set
correctly.

> Neat idea!
>
Cool! Thanks for the bug rept.

[Peter Michaux]

On Feb 17, 10:51 pm, dhtml <dhtmlkitc...@gmail.com> wrote:

[snip]

> Now I need a test to make sure the constructor property is set
> correctly.

I don't ever use the constructor property and I doubt many folks do.
It isn't worth the trouble to keep it "correct".

Then again, I never overwrite the initial prototype property of a
function anymore so I'm not screwing up the constructor property in
the first place.

Peter

[RobG]

Are you persisting with FORK? Or have you decided that the "code
worth recommending project" (cwrp) will form the basis of a (new?)
modular FORK?

Perhaps dhtml can use the cwrp as the basis for a modular library else
it seem the effort is already forked (gosh, my puns are nearly as bad
as Linus T's).

--
Rob

[dhtml]

On Feb 16, 2:19 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 16, 1:14 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>

> <URL:http://peter.michaux.ca/article/7146>

Try the |in| operator.
var xhr = new ActiveXObject('Microsoft.XMLHTTP');
'open' in xhr;

Or, if you don't like |in|, you could use:

Object.prototype.hasOwnProperty.call(xhr, 'open')

Garrett

> Peter

[Peter Michaux]

I don't quite know what will happen yet. David seems to be working on
a library and I have enjoyed all of the discussion that the code worth
recommending project prompted. I'm currently using the Fork code in
work and it has been working fine for me without any changes for a
year.

Peter

[David Mark]

On Feb 18, 9:51 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 17, 11:34 pm, RobG <rg...@iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 18, 5:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Feb 17, 10:51 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > [snip]
>
> > > > Now I need a test to make sure the constructor property is set
> > > > correctly.
>
> > > I don't ever use the constructor property and I doubt many folks do.
> > > It isn't worth the trouble to keep it "correct".
>
> > > Then again, I never overwrite the initial prototype property of a
> > > function anymore so I'm not screwing up the constructor property in
> > > the first place.
>
> > Are you persisting with FORK?  Or have you decided that the "code
> > worth recommending project" (cwrp) will form the basis of a (new?)
> > modular FORK?
>
> > Perhaps dhtml can use the cwrp as the basis for a modular library else
> > it seem the effort is already forked (gosh, my puns are nearly as bad
> > as Linus T's).
>
> I don't quite know what will happen yet. David seems to be working on

Things are as they seem in this case. Did you check out the Alpha I
posted a month back? The Beta should go live this weekend and I will
invite everybody to try it out (criticism and suggestions will be more
than welcome.)

> a library and I have enjoyed all of the discussion that the code worth
> recommending project prompted. I'm currently using the Fork code in
> work and it has been working fine for me without any changes for a
> year.
>

I recently surveyed FORK (Fork?) and it looked quite good. Though I
imagine there are things you would change after all of the various CWR-
related discussions.

[Peter Michaux]

On Feb 18, 7:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 18, 9:51 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
> > On Feb 17, 11:34 pm, RobG <rg...@iinet.net.au> wrote:
>
> > > On Feb 18, 5:07 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > > On Feb 17, 10:51 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > > [snip]
>
> > > > > Now I need a test to make sure the constructor property is set
> > > > > correctly.
>
> > > > I don't ever use the constructor property and I doubt many folks do.
> > > > It isn't worth the trouble to keep it "correct".
>
> > > > Then again, I never overwrite the initial prototype property of a
> > > > function anymore so I'm not screwing up the constructor property in
> > > > the first place.
>
> > > Are you persisting with FORK? Or have you decided that the "code
> > > worth recommending project" (cwrp) will form the basis of a (new?)
> > > modular FORK?
>
> > > Perhaps dhtml can use the cwrp as the basis for a modular library else
> > > it seem the effort is already forked (gosh, my puns are nearly as bad
> > > as Linus T's).
>
> > I don't quite know what will happen yet. David seems to be working on
>
> Things are as they seem in this case. Did you check out the Alpha I
> posted a month back?

I have been reading the code which has been a big help. The builder is
a great feature.

> The Beta should go live this weekend and I will
> invite everybody to try it out (criticism and suggestions will be more
> than welcome.)

How do you feel about promoting your library? With Fork, I found out
almost instantly that I didn't want to promote it aggressively. Folks
that run the YUI, jQuery, Dojo, Prototype libraries go to a lot of
conferences and have birthday parties, etc. Some of the libraries have
people designated as evangelists, I believe. I don't have a problem
with any of that and it is why the libraries are popular.
Theoretically popular means more people reading the code and reporting
bugs. Those projects do have bug fix releases and so that part is
working.

> > a library and I have enjoyed all of the discussion that the code worth
> > recommending project prompted. I'm currently using the Fork code in
> > work and it has been working fine for me without any changes for a
> > year.
>
> I recently surveyed FORK (Fork?) and it looked quite good. Though I
> imagine there are things you would change after all of the various CWR-
> related discussions.

Indeed there are. It is working fine for me because I only use it on a
site behind login with tech-savvy users. No complaints.

I like the API in general but would drop the namespacing to just one
level. I don't know why I can't mentally just go to global functions
like FORK_addistener. What is wrong with that anyway?

-----

By the way, I think I'll be posting the tabbed pane article tonight. I
just need to have it tested remotely on some very old Safari versions.
Thanks for all the help. I'm interested to see if people will read it
and comment.

Peter

[Peter Michaux]

On Feb 18, 5:31 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Feb 16, 2:19 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Feb 16, 1:14 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > <URL:http://peter.michaux.ca/article/7146>
>
> Try the |in| operator.
> var xhr = new ActiveXObject('Microsoft.XMLHTTP');
> 'open' in xhr;

That's an interesting suggestion. The typeof test gives a little more
information, though.

> Or, if you don't like |in|, you could use:
>
> Object.prototype.hasOwnProperty.call(xhr, 'open')

I don't know that sending a host object to a JavaScript function that
expects a JavaScript object is a good idea. That isn't a totally
coherent sentence but it makes me nervous anyway. The typeof test
gives more information here also.

Thanks,
Peter

[David Mark]

Glad to hear it. I have heard positive things from others as well,
despite the fact that there were numerous problems with the Alpha
(most related to the management of dependencies by the builder.) What
I am arbitrarily calling the Beta is much improved and is much larger
in scope (I know that is an ill-advised design strategy, but this
project is a hobby for me.)

>
> > The Beta should go live this weekend and I will
> > invite everybody to try it out (criticism and suggestions will be more
> > than welcome.)
>
> How do you feel about promoting your library? With Fork, I found out

I don't have anything special planned. I certainly hope that those
who find it useful "digg" it (or whatever) for others to discover. My
primary purpose for writing it is eliminate the "there's nothing
better out there" excuse for aspiring application developers.

> almost instantly that I didn't want to promote it aggressively. Folks
> that run the YUI, jQuery, Dojo, Prototype libraries go to a lot of
> conferences and have birthday parties, etc. Some of the libraries have

I don't go to any conferences. I do occasionally have birthday
parties, but most (if not all) who attend have never heard of
JavaScript.

> people designated as evangelists, I believe. I don't have a problem

I won't be handing out such designations. People can say what they
will.

> with any of that and it is why the libraries are popular.

That and the fact that most of them are equally execrable. I think it
is a "pick your poison" mentality that drives people to use these
things.

> Theoretically popular means more people reading the code and reporting
> bugs. Those projects do have bug fix releases and so that part is
> working.

Working at a snail's pace for most. And at worst, waffling rather
than working. I don't consider swapping out browser sniffs to be bug
fixes.

>
> > > a library and I have enjoyed all of the discussion that the code worth
> > > recommending project prompted. I'm currently using the Fork code in
> > > work and it has been working fine for me without any changes for a
> > > year.
>
> > I recently surveyed FORK (Fork?) and it looked quite good. Though I
> > imagine there are things you would change after all of the various CWR-
> > related discussions.
>
> Indeed there are. It is working fine for me because I only use it on a
> site behind login with tech-savvy users. No complaints.

It looked suitable for use on the public Internet to me. Certainly
more so than things like Prototype and jQuery. As you don't sniff
browsers, the code will probably not require major changes as time
goes on.

>
> I like the API in general but would drop the namespacing to just one
> level. I don't know why I can't mentally just go to global functions
> like FORK_addistener. What is wrong with that anyway?

For one, some browsers (e.g. Opera) are slower to resolve global
identifiers. For two, imagine if you had hundreds of functions.
Granted, the FORK_ prefix would likely prevent collisions, but such
precautions aren't required when using a single global object as a
namespace.

>
> -----
>
> By the way, I think I'll be posting the tabbed pane article tonight. I
> just need to have it tested remotely on some very old Safari versions.

I'll check it out.

> Thanks for all the help. I'm interested to see if people will read it
> and comment.
>

How are you promoting it?

[Peter Michaux]

On Feb 18, 8:17 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 18, 10:17 pm, Peter Michaux <petermich...@gmail.com> wrote:

[snip]

> > How do you feel about promoting your library? With Fork, I found out
>
> I don't have anything special planned. I certainly hope that those
> who find it useful "digg" it (or whatever) for others to discover. My
> primary purpose for writing it is eliminate the "there's nothing
> better out there" excuse for aspiring application developers.

I don't think this will make it popular. I believe people want to use
a library that many other people are using so they don't commit to
using a project and then the project dies. Hype works for building
library popularity by building the necessary sense of momentum. I know
you will be using your code so it won't just up and die but other
people don't know that.

> > I like the API in general but would drop the namespacing to just one
> > level. I don't know why I can't mentally just go to global functions
> > like FORK_addistener. What is wrong with that anyway?
>
> For one, some browsers (e.g. Opera) are slower to resolve global
> identifiers.

But resolving FORK_addListener is faster than resolving
FORK.addListener because FORK is global and then a property of FORK
must be found. If a local copy of the function is kept in some scope
then there is no difference.

> For two, imagine if you had hundreds of functions.
> Granted, the FORK_ prefix would likely prevent collisions,

The MM_ functions are still out there going strong and unclobbered.

> but such
> precautions aren't required when using a single global object as a
> namespace.

Actually I think that FORK_addListener is less likely to be clobbered
than FORK. It's all a crap shoot with this single global namespace
business. I'm just glad I don't inject my code into mashups with seven
libraries running simultaneously.

> > -----
>
> > By the way, I think I'll be posting the tabbed pane article tonight. I
> > just need to have it tested remotely on some very old Safari versions.
>
> I'll check it out.

I just posted it. You'll notice I changed the feature detection for
getElementsByTagName. I think that was the only feature test that made
me nervous because I was assuming the document.all fallback for '*'
tagName. Sure enough when I tested in Safari 1.0 the whole widget
crapped out. Safari 1.0 has getElementsByTagName, doesn't support '*',
and doesn't have the document.all fallback. It just goes to show that
it really is necessary to test everything.

I have to read the article through a couple times while it is live.
Somehow little things pop out at me when I finally see it live.

By the way, the comments in the feature detection article really show
how little people know about the topic. I removed the comment thread
about c.l.js from that article because I really don't want a flame war
on my blog. That is the beauty of moderation. It would be awful to
have moderation in c.l.js (even though people could be friendlier) but
on my blog I just don't want to have that going on.

> > Thanks for all the help. I'm interested to see if people will read it
> > and comment.
>
> How are you promoting it?

When I write an article I think might interest others I email the
ajaxians and tell them about it. I think I've done this four times.
They have a news email link down in the right column of http://ajaxians.com.
When they post something to their page that usually means 1500 to 2000
visitors to the article in a single day. Some people have mentioned my
articles on reddit and that usually sends 1000 to 1500 people per day
while it is on the front page. The articles that get linked these ways
also stay the most popular articles for ever after.

Peter

[David Mark]

On Feb 19, 1:14 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 18, 8:17 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Feb 18, 10:17 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> [snip]
>
> > > How do you feel about promoting your library? With Fork, I found out
>
> > I don't have anything special planned.  I certainly hope that those
> > who find it useful "digg" it (or whatever) for others to discover.  My
> > primary purpose for writing it is eliminate the "there's nothing
> > better out there" excuse for aspiring application developers.
>
> I don't think this will make it popular. I believe people want to use

I don't intend to expend any effort to make it popular. It will be or
it won't.

> a library that many other people are using so they don't commit to

You start with a couple of users, then they tell two friends, who tell
two friends, etc. If the inherent virality of the Web fails to
promote what I consider a superior mousetrap, then we will likely be
overrun by mice in the future. I'm not too worried about it.

> using a project and then the project dies. Hype works for building

If the project is well-documented and relatively future-proof (I need
to work on the former), then it will never die.

> library popularity by building the necessary sense of momentum. I know

I don't plan to utilize dedicated evangelists, paid spokesmen or
shills. The project will have to build momentum on its own volition.

> you will be using your code so it won't just up and die but other
> people don't know that.

I will endeavor to ensure that people at least know that.

>
> > > I like the API in general but would drop the namespacing to just one
> > > level. I don't know why I can't mentally just go to global functions
> > > like FORK_addistener. What is wrong with that anyway?
>
> > For one, some browsers (e.g. Opera) are slower to resolve global
> > identifiers.
>
> But resolving FORK_addListener is faster than resolving
> FORK.addListener because FORK is global and then a property of FORK
> must be found. If a local copy of the function is kept in some scope
> then there is no difference.

That's true. But then you have to create an internal "shortcut"
reference for every function (not just those exposed as part of the
API.)

>
> > For two, imagine if you had hundreds of functions.
> > Granted, the FORK_ prefix would likely prevent collisions,
>
> The MM_ functions are still out there going strong and unclobbered.

Next time I see one of those miserable things, I am going to clobber
it. But seriously, those are always the first things I crop out of
sites when performing a salvage operation. They are all worthless,
outdated nonsense.

>
> > but such
> > precautions aren't required when using a single global object as a
> > namespace.
>
> Actually I think that FORK_addListener is less likely to be clobbered
> than FORK. It's all a crap shoot with this single global namespace

But if you have hundreds of targets instead of one, then the
probability of collisions is increased. I do see your point that
"FORKINGLEAVETHISALONE" would be a less likely candidate for an
overwrite.

> business. I'm just glad I don't inject my code into mashups with seven
> libraries running simultaneously.

I think that goes without saying. But theoretically you should be
able to co-exist with most libraries.

>
> > > -----
>
> > > By the way, I think I'll be posting the tabbed pane article tonight. I
> > > just need to have it tested remotely on some very old Safari versions.
>
> > I'll check it out.
>
> I just posted it. You'll notice I changed the feature detection for
> getElementsByTagName. I think that was the only feature test that made
> me nervous because I was assuming the document.all fallback for '*'

Certainly the similar code in CWR doesn't make such an assumption. I
know the original version I wrote detected document.all.

> tagName. Sure enough when I tested in Safari 1.0 the whole widget
> crapped out. Safari 1.0 has getElementsByTagName, doesn't support '*',
> and doesn't have the document.all fallback. It just goes to show that

In that case, you should get an invalid result back from getEBTN when
passing "*" for the tag. It is up to the application to deal with
that anomaly (i.e. bail out or abort from the start.) Personally, I
never query for "*" as I know that it is prone to errors and the
workaround is not universally available.

> it really is necessary to test everything.

Why are you passing "*" to getEBTN anyway?

>
> I have to read the article through a couple times while it is live.
> Somehow little things pop out at me when I finally see it live.

I'll comment on it when I get a chance. Probably tomorrow.

>
> By the way, the comments in the feature detection article really show
> how little people know about the topic. I removed the comment thread
> about c.l.js from that article because I really don't want a flame war
> on my blog. That is the beauty of moderation. It would be awful to
> have moderation in c.l.js (even though people could be friendlier) but
> on my blog I just don't want to have that going on.

Do you mean the person who commented twice in a row with virtually the
same sentiment about rude behavior? How rude was that?

>
> > > Thanks for all the help. I'm interested to see if people will read it
> > > and comment.
>
> > How are you promoting it?
>
> When I write an article I think might interest others I email the
> ajaxians and tell them about it. I think I've done this four times.

The Ajaxians have landed?! Are they friendly?

> They have a news email link down in the right column ofhttp://ajaxians.com.

> When they post something to their page that usually means 1500 to 2000
> visitors to the article in a single day. Some people have mentioned my
> articles on reddit and that usually sends 1000 to 1500 people per day
> while it is on the front page. The articles that get linked these ways
> also stay the most popular articles for ever after.

Do you add links to social bookmarking sites as well? They seem to be
a popular way of sharing resources. Personally, I have never even
signed onto one of them, but I may so I can "digg" my own pages. As
far as Website promotion goes, that's about the most effort I am
willing to expend.

[Peter Michaux]

On Feb 18, 11:02 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 19, 1:14 am, Peter Michaux <petermich...@gmail.com> wrote:

> Do you add links to social bookmarking sites as well?

No. I just email Ajaxian and that is it. I'm not an evangelist other
than what I write. A big part of writing the articles is to get the
ideas straight in my head. Once I do that I want to move on to
learning something new. You know, this whole tabbed pane article has
just been a way to procrastinate writing a new function for Emacs. I
really don't want to write this one. It is a real pain. But I suppose
it is back at the top of the heap now :-( Seriously I've wanted to
write the tabbed pane article for a long time. It was going to be
about something totally different though: the different architectures
to write a widget like using closures or OOP.

Peter

[dhtml]

// version 3
function isHostMethod(object, property) {
return !!(typeof object[property]) ||
// For compliant objects which have a typeof
// result which is an empty string.
//
// Would error for ActiveX but
// will have returned already.
object[prototype];
}

isHostMethod(document, 'foo')

Is clearly broken.
It gets to

typeof object[property], that's a string.
!converts to false,
!! converts to true

the method returns true. always.

If it were to get to the second part,
object[prototype]

would cause an referenc error.

Garrett
> Peter

[Peter Michaux]

Also note my typo ^^^^^^^^^

>
> }
>
> isHostMethod(document, 'foo')
>
> Is clearly broken.
> It gets to
>
> typeof object[property], that's a string.
> !converts to false,
> !! converts to true
>
> the method returns true. always.

Thanks for pointing this out. This is not the function I meant to
post. What I meant was the following, not to say that I haven't made a
mistake here.

function isHostMethod(object, property) {
return typeof object[property] == 'unknown' ||

// Would error for ActiveX but
// will have returned already.

object[property];
}

> If it were to get to the second part,
> object[prototype]
>
> would cause an referenc error.

I don't think that is true. It is ok to access an undefined property
of an object. What is not ok is referencing a undeclared variable.

Thanks again,
Peter

[Henry]

On Feb 19, 5:47 pm, dhtml wrote:
> On Feb 16, 2:19 pm, Peter Michaux wrote:
<snip>

> // version 3
> function isHostMethod(object, property) {
> return !!(typeof object[property]) ||
> // For compliant objects which have a typeof
> // result which is an empty string.
> //
> // Would error for ActiveX but
> // will have returned already.
> object[prototype];
>
> }
>
> isHostMethod(document, 'foo')
>
> Is clearly broken.
> It gets to
>
> typeof object[property], that's a string.
> !converts to false,
> !! converts to true

No, the empty string has falseness (and is the only string primitive
value for which that is the case). The NOT operator converts the empty
string to boolean true, and double NOT will result in boolean false
when the subject is an empty string.

> the method returns true. always.

<snip>

Not always.

[Peter Michaux]

This is what I was thinking at the time and of course forgot that
moments ago. Regardless the test above is not very useful. If the
typeof results is "undefined" then the function returns true and I
still wouldn't know if I can call the property.

Peter

[Thomas 'PointedEars' Lahn]

Peter Michaux wrote:
> String.prototype.normalize =
>
>
> Really bad. This is a major problem with Prototype and has burned them
> when a browser implements the very same function. If you are keen on
> namespacing then you definitely shouldn't be playing with common
> objects.
>
> "Don't modify objects you don't own."
>
> Do this...
>
> function normalizeString(string) {}

You are not making much sense here.

First of all, it is the ECMAScript implementation, not the browser, that
would implement this method. Therefore, there could only be two equally
probable outcomes: a) the implementation-defined property has the attribute
ReadOnly, and the implementation-defined property value is kept or b) the
implementation-defined property does not have the attribute ReadOnly, and
the implementation-defined property value is overwritten. With b) a more
efficient implement implementation would be overwritten by a less efficient
one. One can assume that both implementations would do what the method
identifier says, so the supposed damage would be negligible.

Second, I don't see anything wrong in augmenting String.prototype (or
Number.prototype, RegExp.prototype aso.), unless one would insist to use
for..in on string values (and numbers, or RegExp objects, respectively).
Your argument would be valid for Object.prototype, because of all native
objects inheriting from that and so with for..in iteration the user-defined
property would show up in a for..in loop with *any* parameter (as that is
converted to a corresponding object on for..in evaluation).

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>

[David Mark]

On Feb 19, 1:47 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Peter Michaux wrote:
> > String.prototype.normalize =
>
> > Really bad. This is a major problem with Prototype and has burned them
> > when a browser implements the very same function. If you are keen on
> > namespacing then you definitely shouldn't be playing with common
> > objects.
>
> > "Don't modify objects you don't own."
>
> > Do this...
>
> > function normalizeString(string) {}
>
> You are not making much sense here.
>
> First of all, it is the ECMAScript implementation, not the browser, that
> would implement this method.  Therefore, there could only be two equally
> probable outcomes: a) the implementation-defined property has the attribute
> ReadOnly, and the implementation-defined property value is kept or b) the
> implementation-defined property does not have the attribute ReadOnly, and
> the implementation-defined property value is overwritten.  With b) a more
> efficient implement implementation would be overwritten by a less efficient
> one.  One can assume that both implementations would do what the method
> identifier says, so the supposed damage would be negligible.
>
> Second, I don't see anything wrong in augmenting String.prototype (or
> Number.prototype, RegExp.prototype aso.), unless one would insist to use
> for..in on string values (and numbers, or RegExp objects, respectively).
> Your argument would be valid for Object.prototype, because of all native

I would add Array.prototype as well, at least if you want your code to
co-exist with other scripts, which may use for-in loops to iterate
through arrays (a bad idea of course, but often seen in practice.)

[snip]

[dhtml]

On Feb 19, 10:02 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 19, 9:47 am, dhtml <dhtmlkitc...@gmail.com> wrote:
>
>
>
> > On Feb 16, 2:19 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > > On Feb 16, 1:14 pm, dhtml <dhtmlkitc...@gmail.com> wrote:

Sorry - I thought I clicked reply to author. I'm really not sleeping
enough these days.

> Thanks for pointing this out. This is not the function I meant to
> post. What I meant was the following, not to say that I haven't made a
> mistake here.
>
> function isHostMethod(object, property) {
> return typeof object[property] == 'unknown' ||
> // Would error for ActiveX but
> // will have returned already.
> object[property];
>
> }
> > If it were to get to the second part,
> > object[prototype]
>
> > would cause an referenc error.
>
> I don't think that is true. It is ok to access an undefined property
> of an object. What is not ok is referencing a undeclared variable.
>

true

Garrett

> Thanks again,
> Peter

[Peter Michaux]

On Feb 18, 10:14 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 18, 8:17 pm, David Mark <dmark.cins...@gmail.com> wrote:

snip regarding feature detection articles

<URL: http://peter.michaux.ca/article/7146>
<URL: http://peter.michaux.ca/article/7217>

> > How are you promoting it?

[snip]

> Some people have mentioned my
> articles on reddit and that usually sends 1000 to 1500 people per day
> while it is on the front page.

Hint to anyone who thinks the web browser community could benefit from
these articles ;-)

Peter

[dhtml]

On Feb 19, 10:07 am, Henry <rcornf...@raindrop.co.uk> wrote:

I think somehow you missed the typeof operator when reading that.

!!(typeof object[property])

If typeof were to return an empty string, what you're saying could be
true. That would be a bug.

I'm not sure why when I click 'Reply to Author' that the reply gets
posted on the list. I know I've replied to posts indivually before and
they've been received.