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() {
//...
}
Object.extend used in my gist is BTW same as backbone's .extend 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. Also
lisper in me thinks that `Object.extend` method is better than dedicated class
syntax cause it keeps language concise. 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`.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (http://goo.gl/maps/3CHu)
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
> > (mailto: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 (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
