Again, thanks for the input! I've changed the site to emphasize that point about Underscore.js (as you suggested), and also added a page explaining more about (not) patching Object.prototype. Still don't want to add docs for "enableSugar"... not sure yet that's the direction I want... may remove it later.
I researched it quite a bit when first looking at what's out there and I think if you look at it closely you'll definitely see a lot of ruby red in there. However I think you're right that it's not a fair statement, so I just took that part out.
First of all I'm impressed with you being objective and not gnawing my head off even after discovering probably the thorniest part of the library (and so soon too)! I am aware of and on your side about the issues with patching the Object.prototype.
So, to be perfectly clear, the Object prototype will NEVER be modified in any way by default! The "enableSugar" method you have found (so resourcefully, I might add :) ) is something I added in later as an "opt-in" way of using objects as hashes in pages where you ALREADY have assurance that it won't break. It is intended as something of the reverse of "noConflict" in jQuery. By using this method you're basically saying that you're ready to live on the edge and will take responsibility for what breaks. More importantly you can turn it off again if something does start to break.
Now that having been said, even though I've added this method there is ZERO reference in it to the documentation. A few reasons for this: one is the backlash I knew I would get for even MENTIONING the sacred Object prototype (you may have proved that point, heh)... the other is that I'm not sure I ever really want it used... in the first place I sort of intended it as more of an "easter-egg" and I'm not sure I ever want to mention it in the docs...
In any case though it will NEVER be a default, and for precisely the reasons you've mentioned.
Trust me, no one wants to prevent it from becoming PHP more than me. If you have to refer back to the docs every 2 seconds, it's not a good thing. My goal is to be as intuitive as possible WITHOUT the docs. There's so much room for improvement when it comes to JS but I'm also very keen about keeping spaghetti methods that overlap one another out as well... it will definitely be a balancing act...
Thank you much for your support of the concept. I have a great respect for _ and love what it does. We definitely have the same goal in mind, with different ideas of how to get there. I'm going to try to be humble and learn as much as I can from great code like theirs while at the same time trying to keep some hard lines about Sugar's commitment to intuitive and easy to understand syntax.
To be clear, "sacrificing" performance is not a goal (obviously) nor should it need to be. The only point is that the ultimate goal is intuitive syntax, and that performance will always take a second place to that. That doesn't mean that I'm not thinking about performance, and it will be a goal of mine over the coming days to improve weak spots and tighten up performance, as that is a priority too. But I really wanted to nail the syntax first to the greatest extent possible.
Honestly, I find it to be more the common superstition rather than the common wisdom. That is not to say there's no truth to it, but I find that I hear ppl repeating it religiously without really knowing why. The main danger comes from extending Object.prototype, which Sugar will never do. In response to a lot of people with the same concerns as you, I've put up a page explaining this in more detail (http://sugarjs.com/native). I think the idea of extending other objects may have gotten a bad rap due to this, but the fact is there is a marked difference, and frameworks like Prototype have known this and found their niche here for many years.
Now of course there are other considerations like collisions with Prototype itself or other libraries. But in the end, any library that modifies these native types is generally speaking meant to exist on it's own, without having to co-exist with other libraries of similar type. Now I realize that can't ever be 100% guaranteed, but if that limits the environments where Sugar can be included, then so be it. Now that having been said I am still going to great lengths whenever possible to minimize these collisions and in more than a few places have actually re-aligned Sugar syntax to match Prototype, so long as it doesn't violate my first rule of having intuitive syntax that "reads". Additionally it's worth restating that Sugar never overwrites methods that are already defined, and so any page that includes Prototype will always get Prototype methods in the case of a collision. I'm currently looking into an elegant way of having devs manually override Prototype methods/classes if they so desire. I also believe that the danger of modifying native objects can be greatly mitigated by extensive unit testing, and this was the main reason I've taken the unit tests as far as I have (to be honest I've gone a bit nuts with them). To summarize, there is a certain extent to which I disagree with the statement that "modifying native objects is bad" and a certain extent to which I agree. To the extent that I agree I think that making good design decisions, mitigating collisions, and having proper unit tests to tie it all together can more than make up for anything that might be considered "bad".
Lastly I want to mention that I just released v0.9.1, which uses Object.defineProperty to map these methods to the prototype. It's a long story (check out MozDev for more info) but the result is that in modern browsers including IE9, modifying the prototype object no longer breaks the for..in loop. I actually had to put a new "warning" into the unit tests that include Prototype because I wanted to put in a unit test assuring this, but Prototype breaks it!
