third_party/WebKit/Source/modules/indexeddb/IDBObserverChanges.idl - Issue 2031113002: IndexedDB Observers

Side by Side Diff

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Side by Side Diff: third_party/WebKit/Source/modules/indexeddb/IDBObserverChanges.idl

Issue 2031113002: IndexedDB Observers (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: IDLObserverChanges interface Created 4 years, 6 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« no previous file with comments | « third_party/WebKit/Source/modules/indexeddb/IDBObserverChanges.cpp ('k') | third_party/WebKit/Source/modules/indexeddb/IDBObserverChangesRecord.h » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 // Copyright 2016 The Chromium Authors. All rights reserved.

	2 // Use of this source code is governed by a BSD-style license that can be

	3 // found in the LICENSE file.

	4

	5 // https://github.com/WICG/indexed-db-observers/blob/gh-pages/EXPLAINER.md#chang es-argument

	6

	7 [

	8 RuntimeEnabled=IDBObserver

	9 ] interface IDBObserverChanges {

	10 readonly attribute IDBDatabase database;

	11 // Transaction contains the same object stores as the transaction on which I DBTransaction.observe was called.

	12 readonly attribute IDBTransaction transaction;

	13 // This is the javascript Map<String, sequence<IDBObserverChangesRecord>>,

	14 // where the key is the object store name.

	15 [CallWith=ScriptState] readonly attribute any records;
	bashi 2016/06/13 01:35:51 Can you elaborate why you don't use maplike<DOMStr Can you elaborate why you don't use maplike<DOMString, sequence<IDBObserverChangesRecord>> ? dmurph 2016/06/13 17:23:52 Unless the bindings generator we have is different Show quoted text On 2016/06/13 at 01:35:51, bashi1 wrote: > Can you elaborate why you don't use maplike<DOMString, sequence<IDBObserverChangesRecord>> ? Unless the bindings generator we have is different than the spec, you cannot declare that as a variable type. It's only meant for describing the type that we're inside. So palak can make a new (dictionary? interface?) type, something like this: interface IDBObserverChangesMap { maplike<DOMString, sequence<IDBObserverChangesRecord>>; } and then use that type as the 'records' attribute type. But the spec doesn't let you use maplike as a type. But maybe our system lets you do that? Palak, what happens when you put that there as the type (not the whole new class, just what bashi suggested). palakj1 2016/06/13 21:30:12 Indeed, as dmuprh pointed out, I cannot declare ma Show quoted text On 2016/06/13 at 17:23:52, dmurph wrote: > On 2016/06/13 at 01:35:51, bashi1 wrote: > > Can you elaborate why you don't use maplike<DOMString, sequence<IDBObserverChangesRecord>> ? > > Unless the bindings generator we have is different than the spec, you cannot declare that as a variable type. It's only meant for describing the type that we're inside. So palak can make a new (dictionary? interface?) type, something like this: > > interface IDBObserverChangesMap { > maplike<DOMString, sequence<IDBObserverChangesRecord>>; > } > > and then use that type as the 'records' attribute type. But the spec doesn't let you use maplike as a type. > > But maybe our system lets you do that? Palak, what happens when you put that there as the type (not the whole new class, just what bashi suggested). Indeed, as dmuprh pointed out, I cannot declare maplike<..> as a varialbe type. I'd need to create a new interface. Since IDBObserverChanges won't ever be created by the user, we can ensure what the type of 'records' is without making it binding in the idl. So, would it be fine if I let 'records' be as is for the time being and change its type to maplike as a part of another patch.
	16 };

	17

OLD	NEW