Hey Nic, This whole thread would belongs in the core mailing list http://groups.google.com/group/prototype-core/
Mind switching it over ? Regarding your patch, a much cleaner way of handling that issue would be to use a closure. Best, Tobie On Jan 30, 2:10 pm, "Nicolás Sanguinetti" <[EMAIL PROTECTED]> wrote: > +1 > > Let's do this and then we'll rule the world--nay, the universe! THE > UNIVERSE, I SAY! MWAHAHAHAHHAHAHAAHAHAHA > > (sorry, just got out of bed, but it *is* a possibility :)) > > -Nicolas > > On Jan 30, 2008 10:36 AM, Richard Quadling <[EMAIL PROTECTED]> wrote: > > > > > On 30/01/2008, Dr Nic <[EMAIL PROTECTED]> wrote: > > > > I've started a path to reimplementing commonly reused global names > > > with a patch (http://dev.rubyonrails.org/ticket/10958) > > > > This patch is for $ function. I've giving it the namespace > > > Prototype.upgradeElement, but the actual name is unimportant currently > > > - its very easy to change in my git branch and to recreate the patch. > > > > Whilst there are many classes and functions in the global namespace, > > > this patch is a start to give an idea how easy it is to replace the > > > code throughout the src, and ensure the original tests still work (and > > > thus all dependent code will still work). > > > > Subsequent patches can fix up other commonly overused variables/ > > > functions, and most importantly, create a noConflict() method to let > > > users manage it at runtime. > > > > Cheers > > > Nic > > > Hopefully, this patch will be accepted. Allowing Prototype to play > > nicely with others sounds like a great facility to me. > > > From a quick scan of the source, the following are added to the global > > namespace ... > > > $, $$, $A, $break, $F, $H, $R, $w > > Abstract, Ajax, Class, Enumerable, Event, Field, Form, Hash, Node, > > ObjectRange, PeriodicalExecuter, Selector, Template, Try > > > By having these as aliases to the namespaced ones, theoretically, > > there is no damage to userland code (there will always be edge cases > > though). > > > So, having these capable of being removed by a Prototoype.noConflict() > > is a good idea too. > > > For those not using another library, there is no need to call the > > noConflict() and they can use the global namespaced created > > references. > > > On the surface, this is a win-win situation. > > > +1 > > > Richard "Occasional patcher" Quadling > > > -- > > ----- > > Richard Quadling > > Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498&r=213474731 > > "Standing on the shoulders of some very clever giants!" --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
