Infrequently Noted

Alex, what's very cool about this article, is that on face value it's about how you can extend dojo.query, which is cool. But then when you see dojo.query as a metaphor for "everything in the Dojo toolkit", you realize what the potential is here.

So "extending" classes directly instead of inheriting from them. Does this run into the problem of messing with a namespace you don't have direct control over, the same way that Dojo tries not to mess with the base Javascript name space (i.e. as Prototype does)?

CpILL:

building on would be creating a function external to query() which handles the inspect task and then returning the NodeList back out. By keeping the NodeList class open and giving you clean injection points to this and many other parts of Dojo, you can pull it apart and customize it as you need to. We also try to name and structure things in ways that allow extensions like these to live peacefully with one another. The goal of Dojo in this respect isn't just to give you useful APIs to use, but rather to give you building blocks which you can mix, match, and even replace as your application demands.

Regards

I'm intreeged but this phylosophy “build with, not on”. What would be the example of "build on" here?