Ok, I see what you're saying now. So in the prototype.js library, the first extension (which ironically happens to be Object.extend), would in your model change from "Object.extend = ..." to "Object.protoType_extend = ..." or something like that, right?
I think that is a fine solution to your dilemma. You are, however, still changing a 3rd party library and thusly upgrading to future versions will require re-changing these definitions. I think others have used that idea with success though. But that goes back to my first comment, in that you are developing a process to manage your libraries. Mine is slightly different, but the point is that some level of manual upkeep is almost always going to be required in this new age of web development until such a day as a good type-safe (and possibly compiled) javascript VM is supplied to us by the powers that be. -----Original Message----- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 03, 2006 12:35 PM To: Ryan Gahl Cc: [email protected] Subject: Re: [Rails-spinoffs] Status of Prototype I just saw that we kind of moved off the list, so I resent our conversation to the list ;) As I see it (and I am by no means an expert, so correct me if I'm wrong) - conflicts (except some code does something really stupid) can only arise if 1) the same names are used for custom added methods of existing classes 2) the same names are used for classes 3) existing methods are overwritten with new functionality I'd say that 3) is no problem with prototype, right? So there remains 1 & 2, which could be fixed by adding a prefix to the extension method and class names, if I see it right. e.g.: protoType_ That would get rid of all maintenance problems - how would it hinder encapsulation, reusability and inheritance? Additionally, I wonder how other js-libraries (e.g. dojo) handle things - obviously, there are less problems with those libraries, I've been told on our mailing list. regards, Martin On 1/3/06, Ryan Gahl <[EMAIL PROTECTED]> wrote: > Well I guess if you're going to use any library that makes any kind of > changes whatsoever to the built-in javascript objects via prototype > hacks, then you must take this level of due diligence in making sure > that one library does not conflict with another. If all your libraries > simply define their own custom objects and the only issue is that some > of those objects are named similarly, then yes, by all means affix a > namespace prefix and be done with it. However, if you choose to use > prototype.js or (as I said) any other frameworks that modify the actual > prototypes of built in javascript objects, then it is not as simple as > applying a prefix. In that case you MUST be very aware of what each > library is doing (as you should anyway), and take good care to resolve > those conflicts. Remember, what you're doing when you choose to use > prototype.js (or a similar framework) is simulate a class-based object > oriented language by hacking the semantics of a prototype-based object > oriented language. Any way around it, we are hacking. As hackers, we > have made the decision to sacrifice some things (maintenance ease), to > gain some things (encapsulation, reusability, easier inheritance based > programming). Until a new version of javascript is released that is > fully type-safe and class-based (maybe never?), these are our options... > > -----Original Message----- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 03, 2006 11:25 AM > To: Ryan Gahl > Subject: Re: [Rails-spinoffs] Status of Prototype > > But that's really a maintenance nightmare for you then, right? > > Shouldn't the problem be easy to solve by adding some prefix to all > object names and method names, and have all javascript libraries do > that? > > Additionally, I am talking here as a committer to a web-development > framework, and I really think we can't force our users through this > maintenance nightmare... Plus, our users brought up portlets as a > topic as well - there is no way of ensuring this kind of compatibility > in an environment like that, right? > > regards, > > Martin > > On 1/3/06, Ryan Gahl <[EMAIL PROTECTED]> wrote: > > I indeed ran into the namespace problem... But I really don't think > you > > need to abandon prototype because of it... You just need to develop > and > > apply a sound process for handling all your jScript libraries. I used > > prototype as my baseline library. For any other frameworks that get > > added to my projects I first check for any possible namespace > collisions > > (I always check new libraries for faulty code and optimization points > > anyway so this is a fairly easy step, albeit tedious). If the new > > library has any namespace contention problems, I simply rename those > > functions and/or apply a new namespace (if possible). If the function > is > > in complete conflict with prototype or another library (or is > > redundant), I have no problems just removing it altogether, carefully > > making sure nothing gets broken and fixing anything that does. > > > > This can definitely lead to small problems with maintenance and > upgrades > > of these other libraries, but I've only really run into 1 instance of > a > > namespace collision. When it comes to javascript libraries though, I > > really have no problems customizing them to fit my implementation > > needs... just some food for thought. Remember, no matter how complex > and > > object oriented we make these libraries, they are still just scripts > > (not compiled optimized binaries), so they are flexible and malleable. > > Do what you need to do to them to make the whole thing work for you. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Martin Marinschek > > Sent: Tuesday, January 03, 2006 10:51 AM > > To: [email protected] > > Subject: [Rails-spinoffs] Status of Prototype > > > > Hi *, > > > > we are using prototype in Apache MyFaces as our javascript library of > > choice. Recently, there has been much discussion on our mailing list > > as to the usability of prototype in a dynamic environments where > > several javascript libraries are used. > > > > The critics of prototype argue that the prototype objects are not > > namespaced - and that prototype extends basic javascript-objects with > > method names that could easily be duplicated by another framework. > > > > Is there a line of defense for prototype here that I can use? I really > > don't want to move everything over to dojo or some other library... > > > > regards, > > > > Martin > > _______________________________________________ > > Rails-spinoffs mailing list > > [email protected] > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > The information transmitted in this electronic mail is intended only > for the > > person or entity to which it is addressed and may contain > confidential, > > proprietary, and/or privileged material. Any review, retransmission, > > dissemination or other use of, or taking of any action in reliance > upon, > > this information by persons or entities other than the intended > recipient > > is prohibited. If you received this in error, please contact the > sender and > > delete the material from all computers. > > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces _______________________________________________ Rails-spinoffs mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
