- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 31 May 2011 23:18:39 +0200
- To: "Adrian Bateman" <adrianba@microsoft.com>, "Jonas Sicking" <jonas@sicking.cc>, "Aryeh Gregor" <Simetrical+w3c@gmail.com>, "Ian Hickson" <ian@hixie.ch>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Tue, 31 May 2011 22:03:49 +0200, Ian Hickson <ian@hixie.ch> wrote:
>> We think this makes the design more future-proof because otherwise and
>> new information required prior to establishing the connection will need
>> to be added to the constructor arguments.
>
> We can easily overload the constructor,
Overloading the constructor would work but having several orthogonal
optional arguments is bad API design, where you'd end up with something
like
new WebSocket(url, null, null, null, null, 'foobar');
instead of
new WebSocket(url, {foo:'foobar'});
> or delay the connection to the
> next time the event loop spins, allowing any additional needed
> information
> to be provided after the constructor has been called.
It seems bad to delay the connection just because the API designers didn't
think about future additions.
> On Mon, 30 May 2011, Simon Pieters wrote:
>>
>> This argues for making the subprotocols argument an object in the API. I
>> think that would be a good change
>
> I don't understand what problem this solves. Can you elaborate?
See above.
--
Simon Pieters
Opera Software
Received on Tuesday, 31 May 2011 21:19:20 UTC