- From: Travis Leithead <notifications@github.com>
- Date: Tue, 09 May 2017 07:57:44 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/148/300191782@github.com>
In 4.3, I'm concerned that the advice given doesn't align with the design expectations around dictionaries. The document states: > The general rule is that stats objects, once created, exist for the lifetime of the PeerConnection that contains them, even when the underlying object they report on is stopped or deleted. This is important in order to report consistently on short-lived objects and to be able to report totals over the lifetime of a PeerConnection. > When an object is closed or deleted, the timestamp member of the stats object stops updating; it is frozen at the time when the object stopped. Yet, the design of a dictionary type in WebIDL is such that it is always a value-copy of the information put into it, thus once created, it has no intrinsic tie back to any platform object, and exists as a pure data object, subject to collection by the GC as soon as it is no longer referenced. It would be counter-design to have the `timestamp` member of the dictionary get updated either proactively (by the platform) or reactively (on demand, by the platform) because it would require the platform to keep track of each dictionary returned from the `getStats` call. If this behavior is desired, than an `interface` type is required (not a dictionary). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/148#issuecomment-300191782
Received on Tuesday, 9 May 2017 14:58:22 UTC