An "extend" operator is a natural companion to <|

David Bruant david.bruant at labri.fr
Mon Jul 18 11:54:14 PDT 2011


Le 18/07/2011 19:32, Allen Wirfs-Brock a écrit :
> I've recently been experimenting with coding both prototypal and class
> based object definitions using the various syntactic forms that are
> currently on the table.  Something has emerged from that which has
> surprised me.  I have never been a big fan of the "extend" method that
> is provided by a number of JavaScript frameworks. However, based upon
> my experiments I'm now think that something like extend solves several
> issues with the declarative object and class declarations that we have
> recently been discussing.
>
> Just in case there is anyone on this list who isn't familiar with
> extend, here is a quick explanation. In most frameworks that support
> it, "extend" is invoked something like this: 
>    obj.extend(extensionObj)
> It copies the own properties of  extensionObj and makes corresponding
> own properties for obj.
Very recently, I have read jQuery source code of jQuery.extend and I
have been surprised to discover that actually not only own properties
are copied. See definition at [1] and the main for-in loop between lines
334 and 360. Do anyone has an idea of why it is like this?


> (...)
>
> So, why use an operator like <& instead of a method named "extend":
> 1)  A big reason is that frameworks already use the extend name and
> the exact semantics we would define for it are only to match the
> current semantics of these frameworks.  By not using that name we
> avoid compatibility issues.
> 2) A operator form such as <& avoids issue of method redefinition and
> can more easily added to existing syntactic forms such as function
> declarations.
> 3) It is conceptually natural a natural companion to <|.  It makes
> sense to learn about the two operators together (particularly with
> regard to object literals on the RHS).
4) It makes static analysis easier. I'm currently working on some
JavaScript analysis, trying to extract out the API of a JS library.
Plenty of cases are easy. However, jQuery, defines its API in literal
objects which "extend" jQuery (see [2], for instance) or
jQuery.prototype (jQuery.fn). Doing a static analysis which will be able
to figure this one out will be extremely hard at the very best and most
likely impossible at all (because it will require my static analysis to
understand jQuery.extend semantics, which sounds impossible to me for now)
Having some syntax for that will make the analysis I want to do not only
possible, but easy.

Having a standardized "extend" method would make the static analysis
possible with the extra burden of making sure it has not been overridden
which is impossible in some cases (think obj[var1 + var2] = 1;).

On a related note, as I said, I'm working on extracting a "JavaScript
API" out of a JS file. For that very purpose, I cannot think of
something more useful than a class syntax.
Overall, I am highly in favor of language constructs that make
Javascript more suitable for reliable and easy machine understandability
as it will allow to extract more useful information just based on the
source code.

> I think <& is a natural companion to <| and is in line with our goals
> to both enhancing object literals and providing a class declarations
> as alternative to stand-alone constructor functions.  It increases the
> expressiveness of object literals for declaratively defining
> prototypal object models and permits simplifications of the proposed
> class declaration form.
Indeed. I really like this proposal.

David

[1] https://github.com/jquery/jquery/blob/master/src/core.js#L304
[2] https://github.com/jquery/jquery/blob/master/src/core.js#L368


More information about the es-discuss mailing list