Andrea Giammarchi wrote: > Daniel it is a non-sense and I tell you why. > > "strict" aim is to guarantee future compatibility, right? > The choice of "strict" means "hey cool and updated browser, you should > behave like that here!" > > So whatever happens there, under strict, it does not matter, 'cause > every other browser will simply use old behaviors which means we have > to both "hard code" and "hard test" because "strict" does not mean we > are sure that error will be generated, it simply means that "some new > browser" will "eventually" generate an error. > > In few words "strict" simply open just another different scenario that > will make JavaScript development even more confusing 'cause we'll have > to handle both quirk and strict modes plus every discrepancy with both > quirk and strict modes we can have in every browser and its "a part" VM. Strict mode is backwards compatible. (Precisely the reason why it's `"use strict";` not `use strict;`) Strict mode is for the developers, not for the users. It doesn't matter if your users are using browsers which have implemented ES5 or not. All you do is hop into a browser that has implemented ES5 when testing and it'll throw the errors so you don't fall into the potholes trying to find where they came from.
Strict mode is a mode which disables and fixes a number of the old counterintuitive and unexpected gotchas inside of JS, as well as providing a mode where the engine has more opportunities to optimize and make code run faster. > Cool? Just multiply by 2 every problem we have right now with > JavaScript, and this is ES5! > > I am not complaining about ES5, I am just being realistic about what > this will mean for us. > > Finally, as somebody said already ages ago, I better prefer to fix > JavaScript AS IS, rather than implement new not-usable stuff that only > few developers will get instantly right. > > It is just my opinion. > > Regards > > On Fri, Aug 14, 2009 at 11:19 AM, Daniel Friesen > <nadir.seen.f...@gmail.com <mailto:nadir.seen.f...@gmail.com>> wrote: > > > > new Person() ES3 style: > create object, set prototype, run user code > Person() ES3 style with !instanceof chunk: > run user code, check for instanceof (walk the proto chain), create > object, set prototype, run user code > ((To be technical; new Person() ES3 style with the !instanceof > chunk)): > create object, set prototype, run user code, check for instanceof > (walk > the proto chain) > > Person() ES5 style: > run user code, create object, set prototype > new Person() ES5 style (object created by new being discarded): > create object, set prototype, run user code, create object, set > prototype > > take your pick, discard an object when adding a new that doesn't > belong, > or run a function and walk the proto chain twice each when > forgetting to > use new. > Other than using fake ES5 in environments where ES5 is not > implemented I > don't see how the new ES5 stuff is any less efficient than the ES3 > methods. > It's not like objects being created then quickly discarded is anything > new in JS. > "foo".bar = "baz"; // creates a object to wrap "foo" so it can set > .bar > on it, then discards that object. > Or rather in every day use: > "foo".substr(1,1).toUpperCase(); // creates an object to wrap "foo", > runs .substr, discards the object, wraps the new string literal in > another object, runs .toUpperCase(), discards the object. > Well, that's basically how it's supposed to behave, I'm not sure > if any > of the interpreters optimized this case enough to avoid discarding > anything while mimicking the defined behavior. > > > And that's not the only thing ES5 adds, don't forget about strict > mode. > Strict mode goes and improves programming using the old ES3 > classfunction based approach. > <script> > "strict mode"; > function Person() { > this.first = ''; > this.last = ''; > } > > new Person(); // Works, no instanceof overhead cruft > Person(); // Throws an error right away because undefined can't have > properties. > </script> > > In ES5 strict mode `this` inside functions is undefined instead of the > global object. > That means that instead of the this.first = ''; meaning window.first = > ''; when you call Person() instead of `new Person()` it means > undefined.first = ''; > Thus rather than setting a global property which depending on your > code > may not throw for awhile and leak into the global object, it'll throw > right away because it can't access/set properties on undefined. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) > [http://daniel.friesen.name] > > Andrea Giammarchi wrote: > > > > Dude, I know what you mean and I use Objeect.create already via > > vice-versa and no flags configuration but imho to better understand > > benefits we should consider better examples. I forgot in this one > > there is another thing to: call the init method over created > instance. > > So, again, our good old ES3 is still better than future > alchemies for > > that purpose, imho. > > > >> On Aug 14, 2009 10:08 AM, "Pauan" <pcxunlimi...@gmail.com > <mailto:pcxunlimi...@gmail.com> > >> <mailto:pcxunlimi...@gmail.com > <mailto:pcxunlimi...@gmail.com>>> wrote: > >> > >> > >> The example chosen was poor. It is true that the example could be > >> trivially implemented right now. > >> > >> Object.create is most useful when either A) using inheritance > without > >> functions, or B) when changing the enumerable, writable, and > >> configurable properties. In that case the extra code would be > needed. > >> The example didn't demonstrate either of those cases, so of > course it > >> looks like meaningless boilerplate. > >> > >> As was said, "You could even chose to make those non-enumerable or > >> lock them with values." That was the point, I believe. It > allows you > >> not only to remove the "new" at the front of constructors, but also > >> allows you to configure property flags. > >> > >> I already provided an example that shows how to do inheritance > without > >> needing constructor functions at all, which I believe was the > primary > >> intent of Object.create. > >> > >> On Aug 14, 1:47 am, Andrea Giammarchi > <andrea.giammar...@gmail.com <mailto:andrea.giammar...@gmail.com> > >> <mailto:andrea.giammar...@gmail.com > <mailto:andrea.giammar...@gmail.com>>> > >> wrote: > >> > >> > We are not under a unified VM (syntax not usable) and I > cannot spot > >> a single > benefit using two c... > >> > >> > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
