On Dec 1, 2006, at 1:32 PM, Karl Guertin wrote:
> > 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. FYI The Lasso community is also heavily OOP, although not a requirement with LASSO. Essentially, there is backwards compatibility to older scripting, but the migration to OOP has been rapid since version 8. Deco > >> 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 -~----------~----~----~----~------~----~------~--~---
