W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

Re: ByteString in Web IDL

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Jul 2013 01:01:15 -0400
Message-ID: <CA+c2ei9FGcKLoB2w5X1fgH_gXqAaVhA6cyYOjg_DsecdUBEwFQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Jul 10, 2013 at 12:45 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/10/13 12:35 AM, Norbert Lindenberg wrote:
>>
>> So there's a new fundamentally broken type in a specification that's the
>> foundation for all Web APIs, just to make it easier to describe a few
>> semi-broken legacy APIs elsewhere
>
> To make it _possible_ to describe them, not to make it easier.

This is not true. It would be possible to describe behavior in prose too.

> There's a lot of stuff in WebIDL that's there only or mostly to be able to
> describe legacy APIs.  named/indexed getters/setters, bytestring, some of
> the weirdness in how single-operation callback interfaces behave,
> legacycaller, [LenientThis], [ImplicitThis], [NamedConstructor],
> [TreatNonCallableAsNull], [TreatNullAs], [TreatUndefinedAs], and probably
> others that I missed.
>
> I agree that it should be more clearly marked which parts are there for that
> reason, of course.

Indeed. Many of these end up getting used in new specs because they
are readily available in WebIDL :(

Going through these would also bring up a healthy debate about what
patterns in legacy APIs are bad ideas to keep using in new APIs. I
personally think that 'stringifier' is something that should be marked
as legacy and a bad idea to keep using for example.

/ Jonas
Received on Wednesday, 10 July 2013 05:02:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC