MM: This extends possibilities for dynamic name clash errors in strict mode.

[Discussion about whether dynamic or static name clashes in object literals should be errors or rightmost-one-wins.]

WH: Whatever we do, let's be consistent. Don't want one rule for explicitly named properties, another confusing rule for dynamically generated properties.

WH: If the spread only uses own properties than it is inconsistent with destructuring.

YK, DH: No, the problem is to figure out the key names for ... and after that we do a Get

MM: Are methods enumerable? (Yes) Then I think this is fatal

DH: We have to look at existing code and all existing code uses for-in+hasOwnProperty

WH: I want substitutability, so that I can pick of properties one by one.

BE:

```js

z = Object.create({w: 42});

obj = {x, y, ...z};

```

WH: Wants w to show up in obj.

JM, BN: If you want to pick up objects from the proto you can use `__proto__`, as in { x, y, ...z.__proto__, ...z }. The other way does not hold (if we include non own by default).

MM: Very confortable with Yehuda's rational that we use own properties to find the property names and then use Get to get the value.

YK: Destructuring is sugar for Get.

WH: Wants destructuring to be sugar for HasOwn+Get as in:

```js

var {x} = obj;

=>

var x;

x = obj.hasOwnProperty('x') ? (THROW?) : obj.x;

```

WH: What is the compelling use case for having ... in patterns?

DH: Consistency with ... in spread.

WH: Doesn't necessarily follow. ... in spread constructs objects. The proposed ... in patterns deletes properties in a rather arbitrary way. As an analogy, we have + to concatenate strings but no equivalent operator to undo the effects of +.

SM: [example of passing function arguments to a wrapper]

MM: In this case one could make a use case for either removing explicitly named properties in the wrapper or leaving them in the object before passing them on.

WH: I can see a weak use case for ... in patterns, but not a strong one yet.

RW: (Arguing for not reaching into prototype in destructuring) The final agreement was that built-ins will always create non-enumerable properties, to stay consistent with the spec. User created object and class properties will remain enumerable and it will be left up to user code to decide how to handle these.

MM: (re: decorators proposal)

YK: my decorators can make individual methods or all methods on a class non-enumerable

MM: I am ok with removing the constraint that duplicate dynamic object properties throw (in strict mode) with the caveat that we also remove the same constraint for duplicate static properties.

## Conclusion/Resolution

- For both strict and sloppy object literals, both computed and static properties no longer have any duplicate name checking.

- Instead, the semantics are strictly left-to-right (i.e. rightmost instance of the duplicate name wins over previous properties of the same name).

## Async Generator Functions (Jafar presenting)

(Jafar to send slides)

DH, YK: Consider the cost of having two semi-compatible but different APIs, Streams and Observables.

DH Might be worth having a layered API in order to let people drop to low level for perf reasons.

YK: We should get more clarity on this.

:: Jafar explains slides ::

** Discussing .observe() / Object.observe() **

YK: Object.observe() takes a callback now, but it doesn't return anything. Could return an observable in the future.

DH: We need to resolve this soon -- having Object.observe() and Observable.prototype.observe is too confusing.

JH: I really prefer the analogy between iterators and observers (observers are inverted iterators). Very hard to think of a new term that fits better than Observable/Observe

YK: JS community has established that .observe() does one thing, and observable/observe doesn't quite fit that pre-existing convention

** discussion about naming of "Observer/Observe" and whether there are alternatives **

BE: Could do -- Iterable : iterator :: Observable : "observer"

YK: Why not subscribable/subscribe

JH: Want to get away from thinking about things in terms of pub/sub. IME with training devs, decoupling brains from pre-existing notions of pub/sub is important

JH: By pub/sub I'm referring to observable minus .return() and .throw(). "pub/sub" pre-existing notions cause ppl to have difficulty with conceptualizing how they can compose with map/filter

DH: 3 competitors: Object.observe, streams, and ?

Need to rationalize

Need Domenic, Raf, and Jafar together to work it out.

WH: What does this do inside an async function*?

while (...) {

yield line1;

await yield line2;

}

Is it just a backpressure issue, or can the first yield (without the await) surprise the observer in some kind of an unexpected state?

YK: I think it's important that the first value in an observable can be published synchronously. Importantly, there are well-motivated use-cases for Observables whose

initial value is ALWAYS synchronously available (like Object.observe), but there are no well-motivated use-cases for APIs that consume promises whose values

are ALWAYS synchronously available.

## Conclusion/Resolution

- Async generators proposal is now in stage 0, for consideration as part of ES7.

- Need to consider more deeply how average programmers are going to make sense of this syntax without understanding it completely.