Hacker News Reader

Comment by flatline | Hacker News Reader

I'm not sure I like the overloading of the "out" keyword for covariant type parameters, but otherwise, pretty cool.

The in/out naming for covariance and contravariance is pure genius! It's much easier to learn and to determine which one to use compared to notations in other programming languages. It would be even better if out weren't already in use for something else, I agree.

I find it easier to remember the difference between "out" and "in", compared to "covariant" and "contravariant".

Yeah, I'm not a huge fan of named parameters, either. Seems a bit superfluous.

Named parameters are awesome. The equivalent pattern in javascript is passing in an options object.

foo({ 'name': 'bar', 'title': 'Bar' });

This means not having to look up what the exact order of options are, nor having to pass in a bunch of null parameters because the one you want is the last parameter. Very cool.

}

Named parameters will be particular useful when calling methods which take bools (rather than a intention revealing enum).

Bingo. You can also avoid the fun Enum.IsDefined that comes with it.

I agree that it makes it "more readable", but that only would matter if intellisense wasn't working. I see the parameters, and they are strongly typed. In JS, this isn't the case, so it is much more helpful (e.g, I can completley screw up types/params and they will probably materialize as some strange behavior. As far as bools, I generally try to avoid having more one or two bools as an argument, unless it's required, and it rarely is.

Obviously, all IMO.

Do you have intellisense in your eyes? A line of code with a handful of named parameters reveals its intentions (and possibly also its correctness) for more readily than a line of code with a laundry list of parameters that you need to mouseover then do a bit of mental juggling to line up which value lines up with which parameter. In doing so you've likely interrupted and degraded your reading of the code and you've definitely degraded your ability to readily spot the difference between correct and incorrect code.

Actually, you guys are right. I realized the flaw in my thought process right after I read seasoup's post.

I do, however, have intellisense in my eyes.

Named parameters make code more readable when used properly. For example, which is more readable?

    var c = new Cube(1, 2, 3)

or:

    var c = new Cube(height: 1, width: 2, depth: 3);

The real advantage of named parameters is the ability to have optional parameters as well. Which means that instead of:

   var c = new X(3, "blue", null, null, null, null, false, true, null, 1, null);

(which, sadly, is an all too common implementation pattern), you can have:

   var c = new X(foo: 3, bar: "blue", baz: false, quux: true, wibble: 1);

Which seems quite a bit better.

Another advantage of named/optional parameters is that you can use them in the construction of immutable objects, whereas you don't get that advantage if you use settable properties.

Reply on news.ycombinator.com