Please some small improvements

John J Barton johnjbarton at johnjbarton.com
Tue Mar 20 15:57:40 PDT 2012


On Tue, Mar 20, 2012 at 2:53 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
>
> On Mar 20, 2012, at 2:10 PM, John J Barton wrote:
>
> I've been reading a lot of nicely written JS in the Traceur compiler.
> They use a very conservative Java-like approach with Constructor
> functions and literal prototype property declarations. Sadly they must
> include workarounds for Object.create:
>
> http://code.google.com/p/traceur-compiler/source/browse/src/traceur.js#80
>
> WebInspector has a bit more rough and ready JS style, eg
>
> WebInspector.View.prototype.__proto__ = WebInspector.Object.prototype;
>
> Here's the irony: we can change the WebInspector code to use
> Object.create() specifically because they do not use object literal
> declarations for functions (and thus one line will make improvement).
>
> Since es-discuss seems quite keen on object literals, a couple of
> small improvements would help code move in your direction:
>
>  A version of Object.create() that takes an object RHS.
>
>
> Because you explicitly mention object literals, I assume your intent would
> be to use an object literal as the second argument to such functions.  For
> example such as is done in [1] that starts out as:
>
>   LoadCodeUnit.prototype = traceur.createObject(CodeUnit.prototype, {
>     allowLoad: true,
>
>     get moduleSymbol() {
>       return this.project.getModuleForUrl(this.url)
>     },
>
>     ...
>
>
> In ES.next, based upon current proposals, the equivalent can be directly
> expressed  using <| without any additional function calls:
>
>   LoadCodeUnit.prototype = CodeUnit.prototype <| {
>     allowLoad: true,
>
>     get moduleSymbol() {
>       return this.project.getModuleForUrl(this.url)
>     },
>
>     ...
>
> In other words, <| is the operator forms of the function you are requesting
> for the object literal use case.

I agree that the <| would be a good match to the use shown in the Traceur code.

However, the example shows a significant pitfall waiting for the
unsuspecting: data properties on the prototype. The allowLoad
properties does appear to be intended as a 'static' or class value. In
projects that never use object literals for data properties, then this
ok. But many devs will use object literals for both functions and
data. Soon or later we get burnt.

I suppose the <| operator has the advantage that linters can probably
report data properties in the RHS at edit time.  Making this a compile
error should be considered.

jjb


More information about the es-discuss mailing list