Re: Proxy-induced impurity of internal methods
On 6 October 2011 06:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Oct 5, 2011, at 9:57 AM, Andreas Rossberg wrote: In summary, I'm slightly worried. The above all seems fixable, but is that all? Ideally, I'd like to see a more thorough analysis of how the addition of proxies affects properties of the language and its spec. But given the state of the ES spec, that is probably too much to wish for... :) I'm not sure what you mean my the last sentence. I have not yet done any work to incorporate proxies into the ES6 draft. Oh, sorry, my remark was unintentionally ambiguous -- it wasn't directed at you. Just the generic rant that the whole ES spec is a horribly ad-hoc, utterly unanalysable beast using the state-of-the-art of language specification from 1960. :) Clearly nothing the editor could or should just fix at this point. If you have specific issues like these a good way to capture them is to file bugs against the proposals component of the harmony products at bugs.ecmascript.org. Proposes resolutions would be good too. I definitely look at reported proposal bugs when I work on incorporating new features into the draft specification. On the other hand I don't guarantee that I will spot or remember all issues raised on this list. So file bugs. Fair enough. This time, however, my comments were mainly meant for Tom Mark, who are working on the proposal right now I think. I refrained from suggesting concrete fixes because they probably have a better idea what semantics they envision. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)
as Zend Certified Engineer I can say == and === have never been a problem ... also there are cases when I *want* coercion! var False = new Boolean(false); if (False) alert(You may say WTF); if (False == false) alert(I may say feature); Best Regards, Andrea Giammarchi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: traits feedback
On Thu, Oct 6, 2011 at 5:44 AM, Brendan Eich bren...@mozilla.com wrote:
[...] We want only own properties, including private-name-object-keyed
ones.
I agree that .{, being a special form with a literal to the right, should
copy private-name keyed properties from right to left. However, doing so
for a non-literal right hand side seems very dangerous. We should consider
this very carefully. I suspect we should reject doing so.
OTOH, both the literal special-form and non-literal library forms should
copy non-enumerable own properties from right to left, making for yet
another difference from de facto Object.extend. With two significant
differences, we should clearly choose another name.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one
You mean by deprecate what, exactly? Web JS is full of var. Making any attempt to migrate a big hunk of it to ES6 require replacing all 'var' with 'let' is a huge tax, since scoping works differently. Ok, how about saying if you use 'let' in a function or at top level, you can no longer use 'var'? That's less of a tax on average, but for a long program or single function, it's as bad. On the web, deprecation is separate from obsolescence. You don't remove the bad old thing until the good new thing is out and about and actually in use. You might have to wait for the bad old thing to wither almost to nothing, all by itself. Sometimes, I wish non-web languages would offer similar backwards compatibility, sometimes, I wish web languages were not burdened by backwards compatibility.. One way to help with this problem is automation: we already accept that compilers translating ES.next to ES.current can help with experimentation, design, and early adaptation wrt new features. In the same spirit, compilers from ES.legacy to ES.current could speed up deprecation of unwanted features. This idea is a generalization of special-purpose refactoring tools that support API migration or schema evolution (as opposed to general-purpose code restructuring). One paper that expresses the idea in more detail is Regrowing a Language Refactoring Tools Allow Programming Languages to Evolve Overbey, Johnson, OOPSLA 2009 http://jeff.over.bz/papers/2009/onward2009.pdf Claus http://clausreinke.github.com/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy-induced impurity of internal methods
On 5 October 2011 21:00, Andreas Rossberg rossb...@google.com wrote:
On 5 October 2011 18:57, Andreas Rossberg rossb...@google.com wrote:
FIXING PROXIES
A particularly worrisome side effect is fixing a proxy. The proxy
semantics contains a lot of places saying If O is a trapping proxy,
do steps I-J. However, there generally is no guarantee that O remains
a trapping proxy through all of I-J!
Again, an example:
var handler = {
get set() { Object.freeze(p); return undefined },
fix: function() { return {} }
}
var p = Proxy.create(handler)
p.x
Firefox 7: TypeError on line 1: getPropertyDescriptor is not a function
V8: TypeError: Object #Object has no method 'getPropertyDescriptor'
Whoops, sorry, I just saw that I screwed up that example. That
behaviour is perfectly fine, of course. Don't have my notes here, I'll
deliver the proper example tomorrow.
Here we go (the last line should have been an assignment):
var handler = {
get set() { Object.freeze(p); return undefined },
fix: function() { return {} }
}
var p = Proxy.create(handler)
p.x = 4
Firefox 7: TypeError on line 1: proxy was fixed while executing the handler
V8: TypeError: Object #Object has no method 'getOwnPropertyDescriptor'
So Firefox rejects this (consistently with its treatment of other
methods), while V8 tries to go on with the DefaultPut, using the traps
from the handler that it still happens to have around. This is not
quite what the rules of DefaultPut imply, but what the (inconsistent)
note says.
A related nit: even for freeze and friends, the restriction on
recursive fix is NOT enough as currently stated in the proxy
semantics. Consider:
--
var handler = {
get fix() { Object.seal(p); return {} }
}
var p = Proxy.create(handler)
Object.freeze(p)
--
Strictly speaking, there actually is no recursive execution of fix()
-- the recursion occurs a few steps earlies, when we try to _get_ the
fix function. Firefox rejects this nevertheless:
TypeError on line 2: proxy was fixed while executing the handler
V8 bails out with a stack overflow:
RangeError: Maximum call stack size exceeded
While this might merely be a nit, it shows that it is _not_ generally
enough to only prevent fixing while _executing_ traps. To be
conservative, it seems like we perhaps have to disallow any reentrant
use of freeze/seal/prevenExt at any point in _any_ internal method of
the same object. But how spec that?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: traits feedback
On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich bren...@mozilla.com wrote: On Oct 5, 2011, at 9:02 PM, John J Barton wrote: PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug is post-y2k. so their implementation was just what could be done, not what was desired. Seems unhistorical :-|. Ok, so what is your theory then? This code was written by two of the premier JavaScript developers. If for..in was intended, then Object.extend should also use for...in. The experiment has been done, and for..in is the correct semantics. If for..in was not intended then what? If developers of this caliber aren't using the new results here, that's really discouraging. Actually there is a third possibility: it really does not matter. The differences are not significant. jjb Trait.create() parallels Object.create() and I gather that Trait.compose() resembles proposed Object.extend(). I wonder if the traits.js 'parallel-universe' could be applied to Trait.resolve(). In my experience resolve() isn't needed, but academic work on traits suggests otherwise, so it might be a good thing to investigate. Tom Van Cutsem should weigh in. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: traits feedback
2011/10/6 John J Barton johnjbar...@johnjbarton.com On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich bren...@mozilla.com wrote: On Oct 5, 2011, at 9:02 PM, John J Barton wrote: PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug is post-y2k. so their implementation was just what could be done, not what was desired. Seems unhistorical :-|. Ok, so what is your theory then? This code was written by two of the premier JavaScript developers. If for..in was intended, then Object.extend should also use for...in. The experiment has been done, and for..in is the correct semantics. If for..in was not intended then what? If developers of this caliber aren't using the new results here, that's really discouraging. Actually there is a third possibility: it really does not matter. The differences are not significant. Actually, I am not sure that having `Object.extend' copy all the enumerable (or all own enumerable) properties by default is a good thing. First, because that copying would be most expensive, and I don't think most usecases would require the parent properties to be copied as well -- not to say it's easier to have conflicts, even if we're talking just about enumerable here, but then, not copying all the own properties, enumerable or not, makes even less sense, imho. Second point being is the expensiveness without bringing in a powerful construct. If you need to grab the properties from an object alongside with its parents, you'd rather use a prototype. And it would be easier in this case if JS supported multiple [[Prototype]]s, like Self does. Object.extend then could be regarded just as a means of copying parent-less objects -- semantic-wise. Third point being that for additional use-cases it's easier to create an abstraction layer that recursively copies the descriptors. About own/own+enumerable, one has to ask what people use these extensions for. Right now, I believe most people are just copying data from one place to another, such that it's okay to copy only enumerable properties. But now, let's take into account that ES5 introduced property descriptors and getters/setters. Also, let's assume people wanted to use these for copying behaviours as well -- ie.: using the objects passed to Object.extend as mixins. In this case, I believe it makes more sense to copy all own descriptors rather than just the enumerable properties, as some behaviours might depend on a property that is there, but was intentionally marked as non-enumerable to avoid problems -- hash implementations could use that. I frankly don't think that these new semantic should be fully backwards compatible with ES3-only code, for I believe ES.next will take a while to be adopted. However, I would like hearing about what people's thoughts are on enumerable+own vs all own property copying without regards to what has been done in pre-ES5 code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: traits feedback
On Oct 6, 2011, at 8:06 AM, John J Barton wrote: On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich bren...@mozilla.com wrote: On Oct 5, 2011, at 9:02 PM, John J Barton wrote: PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug is post-y2k. so their implementation was just what could be done, not what was desired. Seems unhistorical :-|. Ok, so what is your theory then? My point was that your PrototypeJS and Firebug pre-date .hasOwnProperty() chronology was wrong. Object.prototype.hasOwnProperty was around since ES3. It was not used in Prototype, but on the other hand, the never extend Object.prototype rule was also promulgated. True, Array.prototype and other built-in prototypes were extended by Prototype. So Object.extend(obj, [1, 2, 3]) would copy inherited methods from Array.prototype to obj, along with properties with keys 0, 1, 2 and values 1, 2, 3 respectively. Given all this, it's not crystal clear what Object.extend is intended to do. It has definite meaning inherent in its self-hosted implementation, but we may not want to standardize only that. And private name objects are new and unforeseen by Prototype's designers. This code was written by two of the premier JavaScript developers. Yes, and we reviewed similar methods a while back from other top JS libraries. See https://mail.mozilla.org/pipermail/es-discuss/2008-July/006709.html http://ejohn.org/files/object-extend.js You're not making an argument from authority, I hope! If for..in was intended, then Object.extend should also use for...in. The experiment has been done, and for..in is the correct semantics. Perhaps, but we have to consider other parts of the language added since then. And with the passage of time and the Object.prototype is verboten lesson, we may come to different conclusions from the original authors. Finally, other libraries differ subtly. If for..in was not intended then what? If developers of this caliber aren't using the new results here, that's really discouraging. I'm not sure what you mean. Do you mean that someone forgot to use hasOwnProperty to filter out inherited properties in the for-in loop? Cc'ing Andrew, he has spoken about this effectively: http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542 http://www.slideshare.net/savetheclocktower/everything-is-permitted-extending-builtins Actually there is a third possibility: it really does not matter. The differences are not significant. That could be. /be jjb Trait.create() parallels Object.create() and I gather that Trait.compose() resembles proposed Object.extend(). I wonder if the traits.js 'parallel-universe' could be applied to Trait.resolve(). In my experience resolve() isn't needed, but academic work on traits suggests otherwise, so it might be a good thing to investigate. Tom Van Cutsem should weigh in. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String concatenation
On Oct 5, 2011, at 9:10 AM, Axel Rauschmayer wrote: The two concatenation approaches I know of are: 1. via += 2. push() into an array, join() it after the last push() (1) can’t possibly be efficient, Huh? Engines have optimized the hell out of 1 by essentially doing 2 under the hood. Even rhino's about a land a patch to do just that. but if (2) is OK on all(!) platforms, then a library would be OK. However, given how frequently this is used, I would like this to become part of the standard library. What exactly do you want supported? Something like Java’s StringBuilder. If, however, (2) collects the concatenated substrings and only joins them on demand in current engines, then there is indeed no need for such a thing. (1) is faster on modern engines. I don't think we need to overdo it here. SunSpider already did :-/. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Grawlix
On 11:59 AM, John J Barton wrote: GrawlixScript is the connection I guess. No, grawlix is a term of art that can be used to describe some the literal syntax proposals. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Grawlix
On 06/10/11 19:56, John J Barton wrote: Recent syntax discussions head in a completely different direction, introducing a seemingly large number of new symbols resulting in code that isn't readable by current JS, Java, or C devs. Instead of JavaScript they will be attempting to read GrawlixScript. I'm skeptical that this direction will be welcomed by developers. There already is lots of complaints about syntax from developers, and they always spring up when someone brings ES.next topic on ##javascript's IRC channel, for example. Though I do believe there are two different groups in this case, those who want syntax either for static/contracts or conciseness, and those who don't want syntax because it makes the language needlessly complex --- neither opposing all syntax proposals or accepting all of them. My personal opinion is that syntax should be kept minimal, while maintaining expressivity. Usually, well designed APIs provide a more expressive interface because you can mix and match them, and they are usually far cheaper (in complexity) than their syntaxes counterpart. Surely, where APIs would otherwise add too much boilerplate, we need syntax. But I don't think that, in a highly dynamic language like JS, declarative/static syntax for every construct should be a major concern. But then, I'm no language designer, only a regular user. And perhaps I've been too much spoiled by Scheme. jjb On Thu, Oct 6, 2011 at 12:19 PM, Douglas Crockford doug...@crockford.com mailto:doug...@crockford.com wrote: On 11:59 AM, John J Barton wrote: GrawlixScript is the connection I guess. No, grawlix is a term of art that can be used to describe some the literal syntax proposals. ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: String concatenation
On 6 October 2011 14:09, Tom Schuster t...@schuster.me wrote: (1) is in fact really good optimized in modern engines. (In case you are interested search for Ropes: an alternative to strings) You don't even need ropes to make this fast for a lot of common cases. I think even a naive implementer would come up with something like this after a couple of beers: - Create the initial string - Mark a bit in the string's private handle (say, a bit in a tagged pointer) when it's referenced - Upon += if the referenced bit is true, goto naive +=, else - realloc() the underlying storage - cat the new string onto the end of the old one - this works whether or not realloc() moves the underlying storage, which it often won't There's all kinds of ways to optimize operations like this. Let's not stifle innovation by over specifying. Incidentally, Tom suggests a great search. The paper is a good read, but the Wikipedia article is a faster skim: http://en.wikipedia.org/wiki/Rope_%28computer_science%29 Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: On Incremental Updates)
You are a gmail user, I surmise. So are others. Gmail collapses cited text, so you don't trim it. Those of us using other mail user agents then have to wade through *pages* of cited text to find your replies, which generally only apply to the last paragraph or two of the cited text. Any googlers among you, please write a letter, or something. Gmail is training everyone to overcite massively. /be On Oct 5, 2011, at 3:11 PM, John J Barton wrote: On Wed, Oct 5, 2011 at 2:25 PM, Russell Leggett russell.legg...@gmail.com wrote: On Wed, Oct 5, 2011 at 1:18 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett russell.legg...@gmail.com wrote: On Wed, Oct 5, 2011 at 11:49 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett russell.legg...@gmail.com wrote: On Wed, Oct 5, 2011 at 10:52 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett russell.legg...@gmail.com wrote: On Wed, Oct 5, 2011 at 10:32 AM, John J Barton johnjbar...@johnjbarton.com wrote: On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel mikesam...@gmail.com wrote: 2011/10/4 Russell Leggett russell.legg...@gmail.com: On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel mikesam...@gmail.com wrote: No it doesn't. Just walk the object graph starting from the root object and let the set of all reachable symbols be A. Load jQuery Walk the object graph again letting the set of all reachable symbols be B. The public API of jQuery is then (B - A). That's works fine under 2 conditions: 1. You're willing to execute code instead of statically analyze it 2. You're capable of executing that code in isolation. This should be true for most libraries out there. It obviously doesn't hold for user code and definitely not for all code in an IDE since IDE's have to deal with code during editing. I'm not a jQuery person, but as far as I can tell jQuery introduces only one global value so the jQuery API is just the properties of that object at the point in the program where the developer needs to use jQuery. You don't have to execute code and the only graph you need to walk is the properties of one object. If you looked at the code for more than 5 minutes, you'd see that the jQuery codebase, while interesting to look at, would be ridiculously hard to statically analyze without understanding jQuery conventions. The bulk of the methods are added through calls to 'jQuery.extend(...' and 'jQuery.fn.extend(...' Sure, that's the way lots of JS code works, which is why I think IDEs based on static analysis are doomed. I was responding to: You don't have to execute code and the only graph you need to walk is the properties of one object. If you don't execute code, that's what static analysis is. I'm sorry, I must be missing something. And the way that jQuery (and any JS code that use a function of some kind to make classes) builds up its api is to use some helper methods, beyond which, static analysis has a really rough time. You don't seem to be disagreeing with me. Oh I got burnt by static analysis before, I should know better. I keep thinking that static analysis means analysis of a single compilation unit outside of the runtime as most IDEs for statically typed languages use. I meant: if your tool is embedded in the run time then it knows the exact jQuery API because it can scan the exact jQuery object. No code on this jQuery object needs to run (though that issue is not a show stopper in practice, witness breakpoint debugging). I don't know what to call runtime analysis that does not run extraneous code. I see, yes. Yeah, I mean if I run the JavaScript console in chrome I get nice autocompletion because its using the running environment to know what properties an object has. I believe this is what a lot of smalltalk IDEs used to do. There are still a lot of limitations, though. I mean, what is the purpose of the analysis in the long run. Modern Java IDEs can do a lot of things with static analysis that are very helpful like refactoring and autocompletion. Look, I'm not trying to turn this into a static vs. dynamic debate, my point is that there are a lot of limitations - and useful tooling that is impossible with dynamic code. I think we got here because someone was trying to make the point that the ability to add statically analyzable constraints would be useful to tooling. And it is on this exact point that we disagree
Re: traits feedback
On Oct 6, 2011, at 12:30 PM, Brendan Eich wrote:
My point was that your PrototypeJS and Firebug pre-date .hasOwnProperty()
chronology was wrong. Object.prototype.hasOwnProperty was around since ES3.
It was not used in Prototype, but on the other hand, the never extend
Object.prototype rule was also promulgated.
JJB has it mostly right. When Sam wrote Object.extend (which was originally
Object.prototype.extend), it didn't use hasOwnProperty; my guess is that Sam
didn't know about it, because most of us were JavaScript amateurs back in the
day, including myself. When I joined the project over a year later, I remember
discussing this problem and discovering that Safari 2.0 didn't support
hasOwnProperty. That, plus the hazard of changing implementation behavior, led
us to leave things as they were. If I were writing Prototype's Object.extend
from scratch, I'd definitely want it to copy own properties only.
Anyway, I'm in favor of standardizing Object.extend in ES6, but in a way that
considers only own properties (including private names, if so desired). I
don't think ES6 should copy the exact behavior of Prototype's (flawed) version
of Object.extend. Whether that takes the form of a method named Object.extend
or a .{ operator… well, that's less important to me, but my vote is for the
former.
(Keep in mind that the 80% use-case for this sort of thing is merging default
options with user-supplied options, at least in the code I write. That's a
simple case that usually involves merging two plain objects without interesting
__proto__ values. That's not to say that we should ignore the edge cases; but
let's just keep them in the proper perspective, and not let them hold up
progress on this front.)
Cheers,
Andrew___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: On Incremental Updates)
repeated with less quotation On Wed, Oct 5, 2011 at 2:25 PM, Russell Leggett russell.legg...@gmail.com wrote: On Wed, Oct 5, 2011 at 1:18 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett russell.legg...@gmail.com wrote: Sometimes going beyond ASTs is extremely challenging - but OK, let's just say we reach a point where we have tools good enough that they can read in code that has been run through a build tool so that they can actually evaluate an entire code base as it would be delivered to the browser. Now what? Do you think that any tool will do a better job of runtime analysis than the tracing JITs that browsers have now? Yes, because the analysis that aids development is not the same as the analysis needed for JIT. The whole goal for advanced JavaScript compilers is to be able to take a JavaScript program which is incredibly mutable and unconstrained, and pin down what the constraints actually are to generate better code. These constraints are what we're talking about, the ability to make certain guarantees. In the case of JavaScript, some of those guarantees are hard to make, whether statically, or at runtime. Additional syntax is a way of adding certain guarantees and I am not entirely opposed to that. That doesn't mean I want to throw everything including the kitchen sink in. And I think we should keep the pressure on the JIT geniuses to continue to deliver ever better performance without making developers add syntax, esp when the additions are based on incomplete or version specific information. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On I got 99 problems and JavaScript syntax ain't one (was: On Incremental Updates)
On Thu, Oct 6, 2011 at 6:40 PM, Brendan Eich bren...@mozilla.com wrote: You are a gmail user, I surmise. So are others. Gmail collapses cited text, so you don't trim it. Those of us using other mail user agents then have to wade through *pages* of cited text to find your replies, which generally only apply to the last paragraph or two of the cited text. I'll try to avoid over citing. I'll request you avoid being quite so obscure. Any googlers among you, please write a letter, or something. Gmail is training everyone to overcite massively. While doing extra work for back level mail agents may not appeal, quoting just the relevant text (usually) makes the arguments clearer no matter the agent. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object.extends (was Re: traits feedback)
On Thu, Oct 6, 2011 at 8:04 PM, Andrew Dupont mozi...@andrewdupont.netwrote: (Keep in mind that the 80% use-case for this sort of thing is merging default options with user-supplied options, at least in the code I write. That's a simple case that usually involves merging two plain objects without interesting __proto__ values. That's not to say that we should ignore the edge cases; but let's just keep them in the proper perspective, and not let them hold up progress on this front.) While I agree with Andrew, I wonder if the issue really edge cases. Rather I guess the problem lies in different vision. Object.extend is a bottom up request for functionality; language experts may object that this function is not needed in a proper class-based language? If all the arguments to Object.extend() have prototype Object, then I guess the function is clear. If any of the arguments have other prototypes, we have cases and choices. for..in: all the properties are merged and the final object has prototype Object keys: only the own properties are merged and the final object has prototype Object. proto-power: non-function own properties are merged; function properties create prototype chain, left to right. I suppose all the above is also possible: for..in: Object.flattenProperties() returned a simple object of the for..in kind. keys: Object.ownProperties() returned a simple object of the own properties of the arguments, proto-power: Object.extend() If Object.create() were upgraded to allow a simple object on the second argument (so the result of the above operations can be passed in), then the base Object functions would do a lot of what devs do now with loops over properties. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.extends (was Re: traits feedback)
From: Andrew Dupont mozi...@andrewdupont.net
JJB has it mostly right. When Sam wrote Object.extend (which was originally
Object.prototype.extend), it didn't use hasOwnProperty; my guess is that Sam
didn't know about it, because most of us were JavaScript amateurs back in the
day, including myself. When I joined the project over a year later, I
remember discussing this problem and discovering that Safari 2.0 didn't
support hasOwnProperty.
For an example of creating a workaround for lack of hasOwnProperty see:
https://github.com/bestiejs/spotlight.js/blob/master/spotlight.js#L189
That, plus the hazard of changing implementation behavior, led us to leave
things as they were. If I were writing Prototype's Object.extend from
scratch, I'd definitely want it to copy own properties only.
MooTools also has an Object.extend() with a bonus that it tries to
avoid IE bugs with for..in over shadowed Object.prototype properties.
I've used similar private `extend()` functions that mimic the
Prototype/MooTools behavior and remember in at least one of my
projects running into problems when attempting to make extend() only
iterate over own properties.
Anyway, I'm in favor of standardizing Object.extend in ES6, but in a way that
considers only own properties (including private names, if so desired). I
don't think ES6 should copy the exact behavior of Prototype's (flawed)
version of Object.extend. Whether that takes the form of a method named
Object.extend or a .{ operator? well, that's less important to me, but my
vote is for the former.
The former, Object.extend, will be hard to add if it is to only
iterate over `own` properties, as I think it should, because
Prototype/MooTools and others add their own Object.extend, without
checking if the method exists, paving any existing method with their
own implementation. This will create inconsistencies between
pages/third-party code that use Prototype/MooTools and those that
don't. Introducing an operator has the advantage of not being
overwritten/mucked-with and allows for shorter/fluid syntax.
I 3 monocle operator!
- JDD
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
