[WIP][NotForLand] IDL dictionary support

Source/bindings/tests/results/TestDictionary.h

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// This file has been auto-generated by code_generator_v8.py. DO NOT MODIFY!
+
+#ifndef TestDictionary_h
+#define TestDictionary_h
+
+#include "bindings/tests/idls/TestInterfaceImplementation.h"
+#include "core/dom/Node.h"
+#include "platform/heap/Handle.h"
+#include "wtf/text/WTFString.h"
+
+namespace WebCore {
+
+class TestDictionary : public GarbageCollectedFinalized<TestDictionary> {

[haraken, 2014/07/21 16:11:59]

It makes sense to enable oilpan by default for IDL dictionaries. There is no
reason to use transition types for new things :)

[bashi, 2014/07/22 02:33:58]

:)

Should I remove Finalized suffix if I want to make the class be a superclass of
some class? (for dictionary inheritance support)

[haraken, 2014/07/22 04:30:10]

"Finalized" is not related to inheritance. "Finalized" controls whether oilpan's
GC should call a destructor or not. If you don't need any destructor of this
dictionary hierarchy, you can omit "Finalized". Otherwise you need "Finalized".

Specifically, you need "Finalized" if the dictionary has members that need
destructors such as RefPtr, String etc. I think you can just add "Finalized"
always.

[bashi, 2014/07/22 05:57:35]

I see. Thanks for the explanation!

+public:
+    static TestDictionary* create()
+    {
+        return new TestDictionary;
+    }
+    TestDictionary();

[haraken, 2014/07/21 16:11:59]

This constructor should be in a private section.

[bashi, 2014/07/22 02:33:58]

Done.

+
+    bool hasBooleanMember() const { return m_hasBooleanMember; }
+    bool booleanMember() const { return m_booleanMember; }
+    void setBooleanMember(bool);
+    bool hasLongMember() const { return m_hasLongMember; }
+    int longMember() const { return m_longMember; }
+    void setLongMember(int);
+    bool hasStringMember() const { return m_hasStringMember; }
+    String stringMember() const { return m_stringMember; }
+    void setStringMember(String);
+    bool hasNodeMember() const { return m_hasNodeMember; }
+    PassRefPtrWillBeRawPtr<Node> nodeMember() const { return m_nodeMember; }
+    void setNodeMember(PassRefPtrWillBeRawPtr<Node>);
+    bool hasTestInterfaceMember() const { return m_hasTestInterfaceMember; }
+    PassRefPtr<TestInterfaceImplementation> testInterfaceMember() const { return m_testInterfaceMember; }
+    void setTestInterfaceMember(PassRefPtr<TestInterfaceImplementation>);
+
+    void trace(Visitor*);
+
+private:
+    bool m_booleanMember;
+    bool m_hasBooleanMember;

[haraken, 2014/07/21 16:11:59]

Can we use Nullable<T>?

[bashi, 2014/07/22 02:33:58]

These members are not nullable (no ? suffix in IDL definition).

IIUC, we need to treat nullable member and non-nullable member separately.
For non-nullable members,
- If a JavaScript object doesn't have the property, it should be treated as
undefined, and |hasXXX()| can be used by blink to check whether it is defined or
not.
- When we create a JavaScript object from dictionary impl class, it should check
|hasXXX()| before setting the property.

For nullable members, we will use Nullable<T> as you suggested (along with
hasXXX() method, for consistency).

The CL doesn't support nullable yet, but I'm going to implement it in next
iteration:)

[haraken, 2014/07/22 04:30:10]

Nullable<T> is not a class just to represent IDL's nullable value, so you can
use Nullable<T> to implement something that might not have a valid value (but
I'm not sure if you can use Nullable<T> in this case.)

How are you planning to implement nullable values? Like this?

  // Non-nullable long.
  int m_longMember;
  bool m_hasLongMember;

  // Nullable long.
  Nullable<int> m_longMember;
  bool m_hasLongMember;

I wonder if we really need both Nullable<> and m_hasXXXMember, since the fact
that m_hasLongMember is false can imply that the value is null. (Probably I'm
not understanding nullable correctly.)

[bashi, 2014/07/22 05:57:35]

This is exactly what I was going to implement. For a member of which type is an
interface, there might be no difference between nullable and non-nullable:

    // Nullable or non-nullable Element
    RefPtrWillBeMember<Element> m_elementMember;
Hmm, it depends on whether we want to handle the notion of 'present'.
http://heycam.github.io/webidl/#dfn-present

Specifically, given
 dictionary A {
  long? longValue;
 };

do we want to distinguish following x and y?
 var x = {}; // longValue is not present
 var y = {longValue: null}; // longValue is present, but null

That being said, I noticed that we may not need to distinguish them when we
convert a JavaScript object to a DOM impl object.
http://heycam.github.io/webidl/#es-dictionary

If I read the spec correctly, null should be treated as undefined.

I'm totally fine using Nullable<T>, but I think we should have hasXXXMember()
method because |longMember().isNull()| looks strange if longMember is
non-nullable.

[haraken, 2014/07/22 07:23:18]

I'm not fully understanding the spec, but if Nullable<T> is enough to support
what we need, I'd prefer using Nullable<T> (because Nullable<T> is introduced to
support these purposes; if it's not enough, we might want to consider improving
the implementation of Nullable<T>). Of course I'm fine with introducing
hasXXXMember() methods.

+    int m_longMember;
+    bool m_hasLongMember;
+    String m_stringMember;
+    bool m_hasStringMember;
+    RefPtrWillBeMember<Node> m_nodeMember;
+    bool m_hasNodeMember;
+    RefPtr<TestInterfaceImplementation> m_testInterfaceMember;
+    bool m_hasTestInterfaceMember;
+
+    friend class V8TestDictionary;
+};
+
+} // namespace WebCore
+
+#endif // TestDictionary_h