On Fri, Oct 14, 2011 at 8:46 AM, Brendan Eich <[email protected]> wrote:
> On Oct 14, 2011, at 10:45 AM, John J Barton wrote: > > On Fri, Oct 14, 2011 at 12:56 AM, Jake Verbaten <[email protected]> wrote: > >> The difference is that object.extend returns objects where as object.make >> returns things with the same type as the second operand. >> >> So object.extend (obj, someFunction) is easy. >> >> where as object.make(obj, someFunction) returns a function. Now clearly >> its a new function so it doesnt share closure state. But then how can you >> say the returned function is the same as someFunction? >> > Sorry I don't understand. I can't imagine any way that object.make() will > return its second argument and that is the only way the returned function > would be the same as the second argument. > > > Yikes, ambiguous language. > > Jake clearly meant "same" as in "twin" or "clone". You are the one > advocating functional purity -- fresh objects, no observable mutation. For > Object.make to be like <| this means the result is not a clone of the first > argument, rather of the second. > > But then Jake's point about closures becomes crucial. Does the function and > its environment get cloned? Closure environments contain mutable bindings. > > This is just one of many "edge cases" already mentioned that plague > attempts to define cloning such that you get the "same" kind of object as > the second parameter, a twin or clone. > > So for the path you are advocating, pure functions that make fresh objects, > you need to specify cloning. That is a tall order. And it's not obviously > needed, since the de-facto standard that <| is codifying and constraining is > the preset-__proto__ use case. There's no common clone pattern in the field, > AFAIK. > To my way of thinking this argument is backwards. In effect you are saying that we can't support object expressions because we can't support function expressions. The priority use cases for setProtoLink operator <| RHS should be objects. Once we have a solution for objects, then we can expand to functions. The common pattern in the field is construction of objects. I've never heard anyone override the Function.prototype for a function literal. It may be useful indeed, I'm not saying it's not. But supporting this should not prevent us from solving the common case. Note that Allen already has special logic for functions on the RHS. In the case case that the RHS is a function. I think what devs want from object.make(obj, someFunction) is a function object with the prototype logic Allen has for <| that runs the function |someFunction| when called. This does not sound hard, but ok maybe it is. jjb > > > This is just one of the edge cases. I would love an object.make as well. > But I cant tell you how to handle all the edgecases. > >> >> >> > The only open question about Object.make(obj, someFunction) that goes > beyond the questions for the protoLink operator <| relates to the difference > between someFunction and a literal function declaration. > > > This sounds like vehement agreement, but you didn't say what that open > question is. It's exactly the "cloning" question. > > /be > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
