I think we're confusing two different cases here:
1) usage of `await` in the body of a function that is not itself marked as
`async`
2) usage of `await f()` where `f` is not marked as `async`.
1 is easy to mark as an early error (and should be imo). 2, not so much
(and is what Mark was asking?)
ot(k, this.[[WCIdentity]]);
if (!slot)
slot = CreateWCSlot(k, this.[[WCIdentity]]);
slot.value = v;
};
WC.prototype.get = function(k) {
var slot = GetWCSlot(k, this.[[WCIdentity]]);
return slot && slot.value;
};
```
On Wed, Dec 3, 2014 at 9:20 AM, Chris Toshok wrote:
> On Thu, Nov
On Thu, Nov 27, 2014 at 10:40 AM, Allen Wirfs-Brock
wrote:
>
> This is the end of my assumed inverted WC design and why I assert that a
> clear method is incompatible with it.
>
>
Couldn't this be solved by adding a little state (a monotonically
increasing 'generation' counter) to the WC? Then,
On Thu, Jun 19, 2014 at 11:06 AM, Erik Arvidsson
wrote:
> On Thu, Jun 19, 2014 at 1:23 PM, Chris Toshok wrote:
>
>> On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson > > wrote:
>>
>>>
>>> On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf <
>>&g
On Thu, Jun 19, 2014 at 10:53 AM, Matthew Robb
wrote:
> What if the `import "module/id";` form was an expression that evaluated to
> the module instance object.
>
> This means everything stays as it is now except we remove the ModuleImport
> form and if you want to use the module instance object
On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson
wrote:
>
> On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf
> wrote:
>
>> One other option could be for import name from 'path' to resolve to the
>> module body there is no default export, thanks to the static analysis
>> you'll always know when de
On Thu, Jun 19, 2014 at 7:13 AM, Calvin Metcalf
wrote:
> > With this idea you cannot look at the import statement to see if the
> imported binding is a module instance object or not.
>
> the flip side of that is that you don't need to know whether something is
> a default export or a named export
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma wrote:
> Is there anything preventing the addition of a "ModuleImport" like
> affordance at a later stage (e.g. ES7)?
>
ModuleImport is the only way (in syntax) to achieve CommonJS `require`
behavior on the consumer-side when a module author exclus
dule, which should not be a pain to declare them explicit
> as imports.
>
>
>> On Mon, Jun 9, 2014 at 12:18 PM, Chris Toshok wrote:
>> Pirouette also has many exports per module for its bindings:
>>
>> E.g.
>> https://github.com/toshok/pirouette/blob/master/
Pirouette also has many exports per module for its bindings:
E.g.
https://github.com/toshok/pirouette/blob/master/bindings/uikit.js.
I use both import-{}-from (with many imported bindings) and module-from forms,
tending toward the former in framework code and the latter in application code.
The
10 matches
Mail list logo
