@name module API

# Erik Arvidsson (13 years ago)

We should really use ''new Name'' instead of ''create''.

import {Name} from '@name'; let myName = new Name;

instead of

module name = '@name'; let myName = name.create();

JS has dedicated syntax for creating new objects. Lets use that. There is also no precedence for ''create'' functions in JS. This would be the first one (second, considering Proxy.create but that was removed)

# Brendan Eich (13 years ago)

Erik Arvidsson wrote:

We should really use ''new Name'' instead of ''create''.

import {Name} from '@name'; let myName = new Name;

instead of

module name = '@name'; let myName = name.create();

+1 from me.

JS has dedicated syntax for creating new objects. Lets use that. There is also no precedence for ''create'' functions in JS. This would be the first one (second, considering Proxy.create but that was removed)

You ignore Object.create in ES5, but I'm hip.

# Kevin Smith (13 years ago)

+1

# Brendan Eich (13 years ago)

Erik Arvidsson wrote:

We should really use ''new Name'' instead of ''create''.

import {Name} from '@name'; let myName = new Name;

instead of

module name = '@name'; let myName = name.create();

To be less content-free in my +1, it seems to me one should always be able to use an identifier as a pattern:

import Name from '@name'; const myName = new Name;

And the built-in module might be named "@std" instead, per harmony:modules_standard, so we'd have

import Name from '@std'; const myName = new Name;

If we can agree that some <script> element variant imports * from "@std"

implicitly as a standard prelude, then we have:

const myName = new Name;

which seems winning to me.

# Irakli Gozalishvili (13 years ago)

I would also expect that

let myName = Name()

will work as it does with other built-ins

-- Irakli Gozalishvili Web: www.jeditoolkit.com