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

Re: Maybe we should think about Interface.isInterface functions again

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 2 Aug 2013 16:27:25 -0700
Message-ID: <CA+c2ei-gt3ANdTy=RiWz-i67v5dX5wjJoUeAtkfvqvUApNB--A@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <domenic@domenicdenicola.com>, Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Aug 2, 2013 at 2:33 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> You are saying that both ArrayBuffer and Blob can be used as data sources or
> sinks and that most clients should be able to work interchangeably with each
> one.  This suggests that there should be a DataSource and DataSink
> interfaces that both ArrayBuffer and Blob should support.  Either by
> directly exposing the methods of those APIs or by expose methods for
> accessing derived DataSource or DataSink objects.
> Or looking at it another way, data that is stored "on disk" can't really be
> manipulated until it is "in core" and that for the Web Platform ArrayBuffer
> is the preferred abstraction over arbitrary "in core" binary data.  In that
> case, websocket I/O with a blob is really just websocket I/O with multiple
> ArrayBuffers.  You might model this (for output purposes, at least). With a
> DataSource interface that produces a sequence of ArrayBuffers.  A DataSource
> over an actual ArrayBuffer would always produce only a single buffer
> sequence.  A DataSource over a Blob could produce a sequence of multiple
> buffers.

DataSource doesn't actually solve anything. It just moves the problem
to whoever implements the DataSource API.

>> So I guess my general meta-point here is that I think type detection
>> is needed. The fact that "instanceof" does see a fair amount of usage
>> seems to indicate that authors feel the need for it.
> And my point is that significant use of type detection is a smell that
> suggests an insufficiently abstracted design.  The fact that "instanceof"
> gets a fair amount of usage indicates that there are a lot of not very good
> designs around.
> There is a point of tension here.  You will here a lot of agile development
> methodologist telling people not to waste time on excessive design or
> abstraction mining. And they're right when they are talking to developers of
> small to moderate sized applications that will have short to medium
> lifespans. In those cases the extra effort required to create a good design
> often just isn't justified.  But if you are building a platform or framework
> that is going to be used by hundreds of millions of developers for decades
> to come,  different economic consideration apply.  Such systems deserve our
> best possible efforts to create great designs.
> Design of good software abstractions isn't easy and even with significant
> effort they're never perfect.  The web deserves our best effort.

I agree that the web deserves our best efforts. But you are arguing
that we should require all developers best efforts. I.e. everyone
should design all of their APIs such that type testing is not needed.

I don't think that's realistic. And that we should plan for that
people need type testing. I.e. I'm arguing that our best efforts
includes supporting people that write imperfect software.

I could be wrong.

/ Jonas
Received on Friday, 2 August 2013 23:28:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC