Change DenoHeaders to be more idiomatic TypeScript

[kitsonk]

This PR changes the way the iterators are defined in Headers.

It uses generators and yields up the values of the private Map. It also leverages the TypeScript type system to guard against values being passed into the constructor, which is where the value of TypeScript comes in. I think we should expect that if code is type safe in TypeScript that we shouldn't need to perform runtime checks.

The assertion of [object Iterator] is something we shouldn't look to test. People should never depend on that for behaviours. Sniffing objects this way is very dangerous and not something we should ever promote. This does produce [object Generator] and yes, the browser implementations produce [object Iterator] but I am not sure why that matters.

In just double checking things, I realise I do need to ensure that new Headers(null) fails though, as that is consistent with the browser behaviour.

[kitsonk]

Based on the discussion on #1056 I am going to rework this to:

• Make the private member a Symbol.
• Create a mixin class to abstract the iterators.

[acconrad]

@kitsonk just a thought here, according to what I've heard from other EcmaScript folks Web IDL private variables are best suited as WeakMaps especially if they need to be shared amongst other other implementation classes (in other words, if it's not truly private but a protected property)

[kitsonk]

@acconrad the private members will be "polyfillable" via WeakMaps. Here, I am not too sure there is value. What we are trying to do is keep things structurally compatible and avoid any potential name collisions. Because "private" isn't really "private" in TypeScript, it means that private member names leak to the public structure and can cause some assignability issues. A Symbol would effectively be ok, as it would be unique and not leak to the public structure, so I think it is better solution in this case (and we don't have to manage a WeakMap of private data, which gets a bit frustrating).

Just to be pedantic, most OO languages allow private access across the same class instances and private fields when delivered in TC39 will have the same behaviour. Protected in traditional OO means that subsequent descendent classes would have access to the member, but not accessible externally, where as descendants don't have access to private (which holds true with both the WeakMaps and TC39 proposal).

[kitsonk]

I am happy now though review from @kyranet and others would be appreciated.

[kevinkassimo]

Looks great!

[kyranet]

The changes look really well, thanks you for this PR, it'll indeed reduce duplicated code in some Web APIs

[kyranet]

LGTM

[ry]

LGTM Thanks!