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: someOptions) *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 values, 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 + FileSystemRights.ReadExtendedAttributes, share: FileShare.None, bufferSize: 64*1024, options: FileOptions.RandomAccess); with inp = new FileStream('foo/bar', FileMode.Open); inp.SetRights(FileSystemRights.ReadData + FileSystemRights.ReadExtendedAttributes); inp.SetShare(FileShare.None); inp.SetBufferSize(64*1024); inp.SetOptions(FileOptions.RandomAccess); 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).