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: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Mon, 5 Aug 2013 08:48:55 -0700
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>
Message-Id: <5F60EC48-D335-46A9-BA8E-ADE637A50625@wirfs-brock.com>
To: Jonas Sicking <jonas@sicking.cc>

On Aug 2, 2013, at 4:27 PM, Jonas Sicking wrote:

> On Fri, Aug 2, 2013 at 2:33 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
>> ...
> 
> DataSource doesn't actually solve anything. It just moves the problem
> to whoever implements the DataSource API.

Moving the need to do such testing from client code, into the implementation layer is a big improvement. 

> 
>>> 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.

In general, yes.  Everyplace a type test is needed is a potential bug farm. If you design APIs that don't require such testing to eliminate them.

We'll never design perfect APIs and occasionally we may end of with a type test.  But we should try to minimize their occurrence. When ever somebody says, "se need a type test" we should be asking "what is it about this API" that necessitates type testing. 

> 
> 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.

Historically language designers could make a similar argument about goto statements.  Some people still use them rather than structured statements, so we should still make and effort to provide good support for labels and arbitrary gotos. 

We can't prevent people from writing poor code, but we don't have to be an enabler of it.

Allen

> 
> I could be wrong.
> 
> / Jonas
> 
Received on Monday, 5 August 2013 15:49:28 UTC

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