ServiceWorker: support Response.{status,statusText,headers} [blink] (2/3)

Source/modules/serviceworkers/HeaderMap.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.
+
+#ifndef HeaderMap_h
+#define HeaderMap_h
+
+#include "bindings/v8/ScriptWrappable.h"
+#include "wtf/Forward.h"
+#include "wtf/HashMap.h"
+#include "wtf/RefCounted.h"
+#include "wtf/text/StringHash.h"
+
+namespace WebCore {
+
+class HeaderMapForEachCallback;
+class ScriptValue;
+
+class HeaderMap FINAL : public ScriptWrappable, public RefCounted<HeaderMap> {
+public:
+    static PassRefPtr<HeaderMap> create();
+
+    // HeaderMap.idl implementation.
+    unsigned long size() const;
+    void clear();
+    bool remove(const String& key);
+    String get(const String& key);
+    bool has(const String& key);
+    void set(const String& key, const String& value);
+    void forEach(PassOwnPtr<HeaderMapForEachCallback>, ScriptValue&);
+    void forEach(PassOwnPtr<HeaderMapForEachCallback>);
+
+    const HashMap<String, String>& headerMap() const { return m_headers; }
+
+private:
+    HeaderMap();
+    void forEachInternal(PassOwnPtr<HeaderMapForEachCallback>, ScriptValue* thisArg);
+
+    HashMap<String, String> m_headers;

[jsbell, 2014/05/23 20:59:49]

Does this maintain order? ES6's Map type has the pesky requirement that
iteration order matches insertion order; WebIDL's [MapClass] may require the
same thing.

(I wouldn't worry for now, but maybe add a FIXME? Do we need ListHashMap?)

[kinuko, 2014/05/26 05:45:13]

No, and yeah the notion of MapClass ordering worried too (that's one of the
reasons I added a comment about compatibility in .idl). Added explicit FIXME
comment here about the ordering.

+};
+
+} // namespace WebCore
+
+#endif // HeaderMap_h