> Changing the core code is NOT the way to go here. An adapter could modify
> the functions to work in harmony without changing prototype
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.$
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.
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at