CARVIEW |
mootools / mootools-core
- Source
- Commits
- Network (129)
- Issues (2)
- Downloads (17)
- Wiki (18)
- Graphs
-
Branch:
master
click here to add a description
click here to add a homepage
Comments for mootools-core


SubZero was my favorite Mortal Kombat karakter.

What about the sub-arguments and sub-collecitons and sub-zero after that?

What about the sub-arrays and sub-objects after that?

Array.prototype.slice creates a clone of the array, yes, however Array.clone is recursive and clones each sub-array and sub-object and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects and every sub-array and sub-object of these sub-arrays and sub-objects

upz yes im sorry, i thought it was the collectionToArray kind of thing.
By the way, doesnt Array.prototype.slice() creates a clone of the array?
Gonna check this out.

Array.clone does not run only in IE.

Thats what the bench shows. Thomas made some.
And remember that this code only runs on IE, so its the only one that should be taken into consideration.

Is doing
new Array(len)
really any faster in JS than[]
?

testing 123

good call. I do in fact need to work some more on the engine detection backwards compat.

You've added konqueror to the UA variable, but shouldn't you add that result to the Browser.Engine.khtml (or even Browser.Engine.webkit)?

You're right...but it doesn't require Hash, BOOM!

btw. it also allows us to do el.adopt(myInstance). I have to admit I rather have flexibility than performance. If you work on a performance crucial part and find that adopt slows your app down maybe you should avoid it in this case.

Yes you are right, that was an accident. Will add it

Browser.js is included after the Types ;)

I don't really like us being forced to accept an array of string ids everywhere we accepts elements. I guess that's more of a 2.0 discussion.
However, it should at least pass in the nocash parameter to be true. Any element that's being acted upon doesn't need to be extended until it's retrieved by a fetching function.

That only works because Hash.extend gets defined in Hash.js, before that (in Browser.js) it is the same as Function.prototype.extend. That's just by convenience of the order of execution, that doesn't make it right. :-)

All type checking should be done inside document.id. Yes, it should be called! :-)

Yes, considering that some people do "adopt('myId')". Maybe we should check if the given value is a string. So we either expect a valid element or a string?