I tend to think an alternate build being available from the website would tend to be confusing to the average consumer, especially given the fact that Object.prototype "insurance" is a goal for an upcoming release (so I've heard...) It won't be very long before Google grabs this thread and exposes the techniques demonstrated to anyone who might be after a temporary fix.
On Apr 24, 4:43 pm, Daniel Friesen <[email protected]> wrote: > I think I like the idea of an alternate jQuery download. > > for ( var i in hash ) /*...@cc loopsafe; if( hash.hasOwnProperty( i ) ) */ > attr[i] = hash[i]; > > Standard jQuery build would contain: > for ( var i in hash ) > attr[i] = hash[i]; > > While a special jquery.loopsafe.js build would contain: > for ( var i in hash ) if( hash.hasOwnProperty( i ) ) > attr[i] = hash[i]; > > The result being that there is an alternate build of jQuery for people > that currently need to deal with legacy code which extends Object.prototype; > I find this to be a fair solution. It gives an option to those who want > to use jQuery in an environment which is already hostile due to legacy > code they slowly want to remove. > But it also caters to the larger group of us that know not to touch > Object.prototype and don't care for the slowdown. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) > > Balazs Endresz wrote: > > Well, if someone really needs a quick *intermediate* solution it can > > be done by inserting checks with search and replace. I didn't think it > > through properly at all but it seems to work if you execute these in > > order (except for the loop around line 3757, where a semicolon should > > be removed after `add( j, this );`). Don't try it on any other script, > > this is only intended for the current (1.3.2) release! > > > loop with braces: > > (for \( (var )?([^\n]+) in ([^\n]+)\) {) > > $1 if ( !$4.hasOwnProperty( $3 ) ){ continue } > > > single line loop without braces: > > (for \( (var )?([^\n{]+) in ([^\n{]+)\) )(?!{)([^;]+;) > > $1{ if ( !$4.hasOwnProperty( $3 ) ){ continue } \n $5 } > > > multiline loop without braces: > > (for \( (var )?([^\n{]+) in ([^\n{]+)\))[^ ] > > $1 { if ( !$4.hasOwnProperty( $3 ) ){ continue } \n $5 } > > > Here's a modified version:http://pastebin.com/m731b1dff > > > On Apr 24, 1:13 pm, DBJDBJ <[email protected]> wrote: > > >> we all then nicely agree, no flames here ;o) > > >> still we have no solution to Captain P. and other jQuery well wishers > >> who have inherited legacy javascript apps and who want to refactor > >> them using jQ only. > >> while having to keep the legacy app running ... > > >> -- DBJ > > >> On Apr 23, 11:06 am, Andrea Giammarchi <[email protected]> > >> wrote: > > >>> @DBJ I know what you mean and I talked about this ages ago in my 5 cents > >>> about javascript prototypal inheritance ... > > >>> Summary, respecting Mozilla convention for other Array cases (forEach, > >>> filter, some, map, etc): > > >>> Object.prototype.forIn = function(callback, self){ > >>> for(var key in this){ > >>> if(this.hasOwnProperty(key)) > >>> callback.call(self, this[key], key, this); > >>> }; > > >>> }; > > >>> // simple test case > >>> Object.prototype.a = 1; > >>> ({b:2}).forIn(function(value, key, object){ > >>> alert(key); > > >>> }); > > >>> Above forIn prototype could be the "de-facto" standard for every library > >>> then we'll find some clever guru that will overwrite that prototype > >>> causing > >>> "disasters" ... the same could be relying the hasOwnProperty method ... it > >>> could be redefined from other silly developers. > > >>> As summary, due to the dynamic nature of the language, Object.prototype is > >>> untouchable but if a library touches it we all should "sign" a deal: > >>> hasOwnProperty has to be the native one so we can all use that method for > >>> each "for in" call (slowing down consistently every browser ... so again, > >>> do > >>> not touch the Object.prototype or you gonna have troubles) > > >>> Regards > > >>> On Thu, Apr 23, 2009 at 10:26 AM, DBJDBJ <[email protected]> wrote: > > >>>> @Andrea > > >>>> Captains text is the best example why you are not supposed to say : > >>>> " ... for people that use obtrusive code that changes the > >>>> Object.prototype..." > > >>>> Faced with a javascript royal mess he inherited, Captain P. trusted > >>>> that jQuery is the way to go. But now his trust is somewhat less > >>>> prominent... > > >>>> Me or you or Captain P. we surely will not extend Object.prototype, > >>>> but still we need jQuery that will work in the presence of a code that > >>>> does this. We do not need to be talled that Object.prototype should > >>>> never be extended. > > >>>> So jQ team, just go ahead and do it ;o) ... There are tons of legacy > >>>> javascript out there with Object.prototype abused comprehensively. > >>>> Right now none of it can be replaced with jjQuery. > > >>>> --DBJ > > >>>> On Apr 22, 2:30 pm, Andrea Giammarchi <[email protected]> > >>>> wrote: > > >>>>> I did not know a native hasOwnProperty method as boolean condition could > >>>>> cause so many troubles but I simply replied to Captain Palapa. It was > >>>>> not > > >>>> a > > >>>>> suggestion for Sizzle, just a quick fix for people that use obtrusive > > >>>> code > > >>>>> that changes the Object.prototype. > >>>>> But, obviously, if Sizzle uses for in everywhere, well ... that is just > > >>>> the > > >>>>> top of the iceberg :-) > > >>>>> Regards > > >>>>> On Wed, Apr 22, 2009 at 2:14 PM, DBJDBJ <[email protected]> wrote: > > >>>>>> I tough of that, seemingly obvious ... but I think it has not > >>>>>> worketh ... > > >>>>>> Also this will require a non trivial jQ+Sizzle refactoring. Lot of > >>>>>> testing, etc ... Me thinks ? > > >>>>>> -- DBJ > > >>>>>> On Apr 22, 9:01 am, Andrea Giammarchi <[email protected]> > >>>>>> wrote: > > >>>>>>> Have you tried this already? > > >>>>>>> 1585: if (Expr.filter.hasOwnProperty(type) && > > >>>> (match = > > >>>>>>> Expr.match[type].exec(expr)) != > > >>>>>>>>>> null) { > > >>>>>>> Regards > > >>>>>>> On Tue, Apr 21, 2009 at 10:02 PM, CaptainPalapa < > > >>>> [email protected] > > >>>>>>> wrote: > > >>>>>>>> Are there any solutions to this issue yet? We're reworking our > > >>>> entire > > >>>>>>>> framework that (prior to my arrival) was a mess of Prototype, > >>>>>>>> ColdFusion CFAjax stuff, Spry, you name it. We're slowly replacing > >>>>>>>> other code with jQuery calls, but it's not going to be an overnight > >>>>>>>> process...and we still have to keep the existing site running. The > >>>>>>>> noConflict() doesn't completely solve all our issues, but sure made > > >>>> a > > >>>>>>>> big difference. > > >>>>>>>> On Mar 28, 2:51 am, DBJDBJ <[email protected]> wrote: > > >>>>>>>>> First: Ok, I will not. It looks silly I know. > > >>>>>>>>> Second + Third : > > >>>>>>>>> -- I do never extend object prototype myself. But 50% of > > >>>> javascript > > >>>>>>>>> users will. As soon as they find some "awesome" snippets on the > > >>>> net. > > >>>>>>>>> The point here is not what me and you (or unavoidable Daniel) > > >>>> know > > >>>>>>>>> and do with jQ. > >>>>>>>>> The point is what majority of jQuery customers do and will do. > >>>>>>>>> My voluntary contribution is to point out what I think general > >>>>>>>>> jQuery public will experience, not us (aka "experts" ;o) > >>>>>>>>> Same as my discusion about context logic: I know what it is > > >>>> and > > >>>>>> how > > >>>>>>>>> is it to be used etc. But at least 50% of jQuery customers will > > >>>>>> either > > >>>>>>>>> never ever > >>>>>>>>> use the context in $() call or will use it but in a wrong way. > >>>>>>>>> Exactly the same is with Object.prototype. > >>>>>>>>> So when real non expert jQuery customer (which is not me ;o) > > >>>> posts > > >>>>>>>>> a finding, > >>>>>>>>> the last thing I want you John (and Daniel ;o) to do is to say > >>>>>>>>> anything along the lines: "this is a wrong question to ask".. > >>>>>>>>> And I do not want you to do this because I think jQuery is > > >>>> very > > >>>>>>>>> good AND equaly importantly has good people "inside". > >>>>>>>>> Also there is a small matter of a typical jQ users blaming jQ > > >>>> for > > >>>>>>>>> their inexperience. As I am sure you are experiencing every day. > >>>>>>>>> There are already blogs where managrs complain how jQ enbaled > > >>>>>> pages > > >>>>>>>>> are becoming slower etc. > >>>>>>>>> Some of them also blog about their developers not using context > > >>>> or > > >>>>>>>>> some other examples of bad Javascript and/or jQ usage. > >>>>>>>>> But most of them do not blog about having bad web developers. > >>>>>>>>> And that leaves bad impression (undeservedly) on jQ. > >>>>>>>>> I think 90% of jQ users until few months ago have been > >>>>>>>>> Web Designers who found out about > > >>>> $("#mydiv").hide("slow").show > > >>>>>>>>> ("slow") and got excited ;o) > >>>>>>>>> With my findings , I just might to help deal with that kind of > > >>>> jQ > > >>>>>>>>> users. Which are making, I am affraid, far more than 50% of jQ > > >>>> users > > >>>>>>>>> population. > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" 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/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
