Dojo to my knowledge adds namespace prefixes... dojo.xxxx
Martin Marinschek wrote: > 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
