I was not prepared for the amount of responses I got to my last article. There really are two camps - and they sit around fires making pointy sticks.

The most constructive was from Rob Sanheim with this post, which got me rather excited.

Now before I code anything, I write a set of testcases. Testcases let you play with your API and sort out the semantics and 'feel' before you get too far into the project to change it. Testcases - Just Do It. (You know who you are).

So within 10 seconds of reading Rob's post I popped the latest prototype.js into my test system and had my result.

I used to have 1 extra dangleberry named 'extend' in every JavaScript Object. At least with that I had a fighting chance.

With prototype.js version 1.4.0 I have 33.

Here they are in all their tentacled glory.

each 
all 
any 
collect 
detect 
findAll 
grep 
include 
inject 
invoke 
max 
min 
partition 
pluck 
reject 
sortBy 
toArray 
zip 
inspect 
map 
find 
select 
member 
entries 
_reverse 
_each 
clear 
first 
last 
compact 
flatten 
without 
indexOf 

Now, I'm not complaining but, oh hang on - I am.

My previous fix for my rendering pipeline is completely out the window.

Now on top of my previous complaint, I'm wondering what the performance hit is for always having 33 objects to check against on every object slot access? In theory if the slot manager uses a good hashtable this won't be more significant than having just one object.

I have a library that can measure this, but prototype.js breaks it.

Its 3 o'clock and on the dark side of breakfast - for now I will sleep on this.