Minimalist (why) classes ?

Irakli Gozalishvili rfobic at gmail.com
Sun Nov 13 21:42:55 PST 2011


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 <brendan at mozilla.com (mailto:brendan at 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 at mozilla.org (mailto:es-discuss at mozilla.org)
> https://mail.mozilla.org/listinfo/es-discuss
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111113/a89922d8/attachment.html>


More information about the es-discuss mailing list