2 bool optional params -- named parameters

[spir]

On Wed, 10 Nov 2010 12:39:15 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Wednesday 10 November 2010 12:24:01 bearophile wrote:
> > Jonathan M Davis:
> > > In any case, the struct solution is the best that I can suggest for the
> > > general case, but really, D doesn't have named parameters. Things just
> > > don't work that way.
> > 
> > Named arguments is among my top four enhancement requests :-) They help.
> > Hopefully in D3.

+++

> I expect that that's one of those things that those who have never used them 
> don't see the point and those who have hate not having them. Personally, I've 
> never used a language that had them, and I don't really care about them. I'd say 
> that if you have parameter lists long enough to care, then your parameter lists 
> are too long and you need to find ways to reduce them (like encapsulating related 
> parameters into struct - using a point struct instead of separate x, y, and z 
> values would be a great example of that).

I fully agree with your struct example for (x,y,z). But this is an example where names, precisely, are not a real gain. The real point is not to reduce the size of a param list (they make it longer!). The real point, in my opinion, is also not avoiding the need to remember param order (and for x,y,z it's not an issue).
Why I love named parameters is that they bring embedded documentation for free; provided names are sensibly chosen, indeed. They make code much easier to read, even for the author. We don't spend our valuable time & attention in "computing" information that should be available (what's that param?). Our brain can then better work on what's important, namely the app's logics. But maybe it's only me.

> Maybe my opinion would be different if 
> I had extensively used a language with named parameters, but I haven't yet.

I first discovered named parameters with python, and loved them before having used them even once. The idea is simply good for me. Either you care for what they bring, or not. It's not a question of beeing used to using them or not.
Probably you give more importance to other aspects of code, and less to the one (say, clarity) greatly enhanced by this feature, than I do. I'm not sure this would change with, for instance, beeing forced to use a language with _only_ named parameters (my dream language *).

> [...]

Denis

From an OO perpective, this is much easier to envision, snce the target, on which a method applies, is already told apart. Then, remaining data are really parameters in the plain sense of the term; and are usually very few. Naming them is thus less a trouble, and more helpful:
	names.sort(ALPHA, true);
	names.sort(order=ALPHA, reverse=true);

-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com