Comments on: Prototype 1.6.0 RC1: Changes to the Class and Event APIs, Hash rewrite, and bug fixes

By: ben

ben — Fri, 19 Oct 2007 13:06:58 +0000

@mislav: whoops, no bug with the domready event, I made a pretty noob mistake in not noticing the reformat of the eventtype (”dom:loaded”), nice way of standardizing eventtypes without losing the context btw ;).
.
Hash class is also nice and cleaner this way, but imagine the overhaul needed for existing applications that built heavily on the hash class =P hash[key].assets[i] ===> hash.get(”key”).assets[i]
.
Also, simulating the getter/setter functionality like this, slows down performance/speed a bit and might be noticable on large scale applications. (which made me stop using objects with getter/setters in some projects, directly changing values is faster).

By: Mislav

Mislav — Wed, 17 Oct 2007 19:35:38 +0000

Ben: I don't know what error are you talking about, but feel free to report the bug properly.

By: advanced

advanced — Wed, 17 Oct 2007 11:05:17 +0000

Sam is my Hero, pave away my man! ..)
Personally I Digg the revised hash class, much cleaner / tighter IMHO.

By: Ben

Ben — Wed, 17 Oct 2007 10:06:08 +0000

ouch… Good update in general, but I think many people will dislike the new Hash changes if they used it extensively.

The domready event on the document namespace needs a looking at, it’s still broken, but at least the embaracing error is gone =P

By: Les

Les — Wed, 17 Oct 2007 03:13:05 +0000

In addition to FF 3, Opera 9.5 supports getElementsByClassName natively.

By: Sam Stephenson

Sam Stephenson — Wed, 17 Oct 2007 00:58:10 +0000

Hi Philip- That's a good question. You're right, getElementsByClassName does not yet exist in all browsers (it's only available in the Firefox 3 alphas now). But Firefox's implementation is incompatible with ours (it returns a NodeList instead of an Array, so you'd need to convert its return value to an array first before using it like you'd be accustomed to using Prototype's), and they've unfortunately chosen to implement it in such a way that prevents us from overriding it with our own version (see Bugzilla #390411 for details). Part of Prototype's design philosophy is that our API should behave consistently on all supported browsers. So in order to pave the way for Firefox 3 compatibility, we'll have to deprecate our implementation of getElementsByClassName. FWIW, Dean Edwards has chosen to do the same in his Base2 library.

By: Joao

Joao — Wed, 17 Oct 2007 00:57:10 +0000

OMG!!! When I tested Prototype 1.6 a few months ago, I found it somewhat clunky in the new Class support, but they seem to have addressed my concerns superbly and I didn’t need to tell them how to do it! Great job! Hopefully this will mean that I’ll be able to adopt it in a huge scale, like in potentially hundreds of classes.

By: Tobie Langel

Tobie Langel — Wed, 17 Oct 2007 00:53:55 +0000

Philip: use $$(’.className’) instead or element.select(’.className’);

By: Mark Holton

Mark Holton — Wed, 17 Oct 2007 00:46:15 +0000

…also new from Prototype:
http://prototypejs.org/learn/class-inheritance

By: Philip Plante

Philip Plante — Wed, 17 Oct 2007 00:32:37 +0000

Maybe I am wrong, but “document.getElementsByClassName” does not yet exist in all the browsers. So how can they remove such a useful function just because FF 3.0 is going to support it in a better way?