> Changing the core code is NOT the way to go here. An adapter could modify > the functions to work in harmony without changing prototype > > > Rick
I fail to see why this is not a perfectly valid "core" modification. The modifications and ideas I've described allow prototypejs to work in an environment where window.$ is not what prototype expects (that is, where window.$ has been changed externally). The fundamental problem with prototypejs now with respect to window.$ (and the problem I am seeking a solution to) is that prototype uses an un-scoped $ internally and is thus very sensitive by what happens to window.$ outside. Again, my proposal is not to directly make prototypejs compatible with library X (although in my case I explicit used jQuery as an example) so much as it reduces a potential problem if window.$ is not prototypejs.$. I do not see how making prototypejs more robust is a bad modification to make. Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
