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
