On 12/1/06, Mislav <[EMAIL PROTECTED]> wrote: > [Opening a class] is true OOP and that is what Rails does to > Ruby built-in types without anyone crying about it. Instead, people > love it. It makes the code shorter, operations more concise and the > whole thing is easier to remember.
The Ruby community does this and nobody else. It's possible in Python, but it's called monkeypatching and is considered a last-case option. I've been bitten doing this, so I'm twice shy. > People are actually afraid only of Array.prototype augmentation, > because they have been using them as associative arrays all this time. I'm against builtin prototype augmentation (henceforth prototype hacking) and I've never used array as an associative array. Because prototype hacking isn't namespaced, doing it on objects that don't belong to you leads to the potential of breaking other people's code. With Object.prototype, the breakage is obvious and I was very happy to see that yanked in 1.4, but the problem with Array.prototype is more subtle. Brendan Eich and the ECMA working group are once again active, so we'll start seeing changes to JavaScript. Array is ripe for improvement, so what happens if the language gets a builtin with the same name as a current prototype extension and a different signature? Will prototype change signature to match and break all the working prototype code? I expect not, I'd anticipate a wrapper function that would preserve signature. Now how does the rest of the javascript world deal with that? They obviously won't be dealing with prototype legacy code so they can use the builtin just fine, but what happens when someone wants to use the scriptaculous autocompleter and pulls in prototype? What if you don't fully control the final page environment? I'll admit that the above scenario probably won't happen because I'd expect the standards guys to be aware of prototype, but it could happen and the possibility is enough for me to delcare prototype hacking on objects you don't own to be evil. There are workarounds like Dean Edwards' iframe trick, so it should be possible to hack around situations like the above if you're aware of the problem, but it wouldn't ever be a problem in the first place if prototype hacking didn't happen. > 2) namespace - Prototype is, in fact, somehow namespaced. The complainers seem to think that somehow it's not... I don't care about this because my stuff _is_ all namespaced, so I'll leave it at that. > YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function. So what do people do? I like MochiKit's solution. If you control the page, you export everything so that you don't have to keep typing the namespaces. If you're writing something to be reused, you can namespace your calls to play along nicely with others. If you're curious, I use TurboGears and MochiKit instead of Rails and prototype, so my position is probably a bit different from most subscribers. I started on prototype about a year ago, realized what Object.prototype extensions implied, and jumped ship. I'm on the list to keep tabs on scriptaculous. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
