On 29/03/2012, at 1:50 AM, John Daughtry wrote:

> You introduced a third option. However, it is a deviation of the 
> implementation behind the interface as opposed to an alternative interface.

I introduced at least three alternative options.  The first of those was what 
*in practice*
create-set-call seems to turn into.  I am not sure what you mean by "a 
deviation of the implementation".
Can you rephrase that?
> Are you suggesting that every API study should consider all of the limitless 
> alternative implementations?

No.  The paper covered what it covered; it covered that pretty well; the more
options you consider the harder (time, people, thinking, money) it gets to do
an experiment.  What I'm saying is that a study with an extremely limited
range of alternatives gets to make extremely limited claims.

The idea of naming parameters in a call goes back to Algol 60, making the idea
at least fifty years old.  I note that modern languages with keyword parameters
include Fortran 95 and >> C# 4.0 <<.

> Perhaps I misunderstood the design alternative you suggest as the third 
> option.
> Your further discussion (e.g., initializer objects) supports the notion that 
> any attempt to achieve both usability and robustness is tedious and laborious 
> in dominant languages.

I just discovered that 'initializer objects' has a name already: Builder.
(It's not clear that they are the same, but the essential point that an
incompletely initialised object is never *exposed* remains.)

I am having a little trouble believing your claim that my discussion supports 
the idea
that doing it right is 'tedious and laborious in dominant languages'.

VB.net and C# 4 have keyword parameters and optional parameters.
To return to

>        new FileStream(String, FileMode, FileSystemRights,
>                FileShare, Int32, FileOptions)

it should be possible to do

        new FileStream(name: aString, mode: aMode, rights: someRights,
                        share: aSharing, bufferSize: anInt, options: 

*if* the constructor had suitable documented argument names.  The arguments can
be ordered freely (that's what keyword arguments are all about) and C# 4.0 has
optional parameters, so you only need to supply the ones with non-default 
and all told, it is really REALLY hard to see how this could be in the slightest
way justly called tedious or laborious.  Compare

        inp = new FileStream(
                name:       'foo/bar',
                mode:       FileMode.Open, 
                rights:     FileSystemRights.ReadData +
                share:      FileShare.None,
                bufferSize: 64*1024,
                options:    FileOptions.RandomAccess);


        inp = new FileStream('foo/bar', FileMode.Open);
        inp.SetRights(FileSystemRights.ReadData +

I am, of course, assuming for the sake of argument that C# counts as a
"dominant language".  I am no admirer of Microsoft or its works, and have
been sniggering happily at the reception of Windows 8.  But C# is very
definitely a better Java than Java.  (And of course it's a better C# (now)
than C# (was) -- the book I was learning C# from only covers C# 2.0.)

I definitely think that it is safe to say that a study that did not
cover a parameter style possible in C# 4.0 is no longer a good basis
for guiding API design in C#.  The presence of keyword arguments in a
language makes a *huge* difference to API design:  in particular a good
choice for a keyword name is _not_ necessarily a good choice for a local
variable holding the same information.  Prepositions can be good keyword
parameter names; seldom or never can they be good variable names.
(Yes, we are still on topic.)

The Open University is incorporated by Royal Charter (RC 000391), an exempt 
charity in England & Wales and a charity registered in Scotland (SC 038302).

Reply via email to