On Nov 13, 2011, at 9:42 PM, Irakli Gozalishvili wrote: > I think this discussion drifted into slightly diff direction. > What I intended to say was that today all major frameworks use same patter to > do subclassing. They all implement different APIs to do the following: > > function subclass() { > // init …. > } > subclass.prototype = Object.create(superclass) > Object.defineProperty(subclass.prototype, 'constructor', { value: subclass }) > subclass.prototype.method = function() { > //... > }
Yes, this is the heart of the matter. Not freezing, not shallow vs. deep property copying (where deep must deal with closures at least). > Object.extend used in my gist is BTW same as backbone's .extend Ok, good to know. (Jashkenas, you didn't propose it!) > and is just a shortcut of the code above: > > var subclass = superclass.extend({ > initialize: function() { > // init ... > }, > method: function() { > // …. > } > }) > > What I'm asking for is a standard function, no matter weather it's > `Object.extend` or something else that makes it simple to do subclassing. Allen has been trying to make it be a combo of <| and .{. Agree there could be a method, say Object.subclass (what a concept!). > Also lisper in me thinks that `Object.extend` method is better than dedicated > class syntax cause it keeps language concise. Sorry, JS isn't LISP. > In addition I think that if `Object.extend` will turn out to be broken it > will be easier (not to say easy) to fix (`Object.extend = … `) then fixing > `class Foo extends Bar`. It would be about as hard either way. /be > > Regards > -- > Irakli Gozalishvili > Web: http://www.jeditoolkit.com/ > Address: 29 Rue Saint-Georges, 75009 Paris, France > > On Sunday, 2011-11-13 at 13:21 , Brendan Eich wrote: > >> On Nov 13, 2011, at 11:28 AM, John J Barton wrote: >> >>> On Sun, Nov 13, 2011 at 9:34 AM, Brendan Eich <bren...@mozilla.com> wrote: >>>> On Nov 13, 2011, at 9:30 AM, Brendan Eich wrote: >>>> >>>>> The hard cases include: >>>>> >>>>> 1. Closures. >>>>> 2. Proxies. >>>>> 3. Private names. >>>>> 4. Internal hidden state. >>>>> 5. Side-table entries mapped to the object's identity. >>>> >>>> In the case of objects implemented by C++ or whatever the host >>>> implementation language might be, the internal or side-table state may not >>>> even be representable in JS, even in strings (do not want raw pointers, or >>>> machine addresses however obfuscated, to leak to an attacker). >>> >>> I think we are on the wrong path here. I guess we followed: a standard >>> extend() needs a copy-ish operation; a copyish operation is like >>> cloning; cloning is hard; OMG. >> >> That's not what happened. Some people are happy with shallow copy of >> properties available to ES5 reflection, or even a for-in loop. Others >> (Rick?) want deep, at least as an option. Deep could skip any >> private/internal/etc. properties, for sure. But deep tends to get into >> trouble because if you don't stay shallow, you run immediately into item 1: >> Closures. How would those be deeply copied, including their lexical >> environments? >> >> >>> But let's back up. We are looking for one or a few operations such that: >>> var a = op(b,c,d,...); >>> creates a useful result when we use |a| and we are using existing JS >>> libraries for guidance. By definition there are no show stoppers here. >> >> I agree, other than inability to agree on what to standardize. >> >> >>> We are creating new objects from existing objects using operations >>> available to JS devs, but in standard and recommended way. The only >>> two things can stop us from being successful: irreconcilable >>> differences and inertia. >> >> Ok, but this is all meta-pep-talk. What should the reconcilable standard be? >> >> /be >> _______________________________________________ >> 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