As alternative, let's move the problem to other libraries via single line:
(function(p){for(var k in p)delete p[k];})(Object.prototype);
and then use Sizzle, jQuery, or whatever you need with a for in loop :D
On Mon, Apr 27, 2009 at 7:00 PM, Ricardo <[email protected]> wrote:
>
> I also like this approach because apparently there's no way to protect
> the loops without downgrading performance or relying on a length
> property. It depends on the way it's presented, I doubt a novice would
> choose to download a version labeled "Object.prototype safe" if he
> doesn't know what it means. And if he does, no harm is done except for
> slightly worse performance. Might aswell do the opposite, an "unsafe"
> version for developers who have full control of their environment.
>
> On Apr 26, 2:59 pm, ajpiano <[email protected]> wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---
