News for hackers. Stuff that matters.
Re:Things I Was Wrong About: Types by jenscow on Sunday September 27, 2020 @09:51AM (#24606609)
A better example for a typed function would be something like:

    function Request(string method, string url, RequestOptions options) : Result {...}
or

    Result Request(string method, string url, RequestOptions options) {...}

Here, we know `url` is a string (rather than the parsed object), we know all the supported options (they're members of the RequestOptions object/enum), and every value in the return value. Some might suggest even making `method` an enumeration.

If the function name was better, you could call that function right now without needing any more information.

Also, especially if you're a fan of defensive programming, most of the basic argument checking is performed at compile time, leaving the function body cleaner.

Based on your example alone, perhaps you don't have enough experience with typed languages to appreciate the benefits. I don't mean that in a belittling way, but more of an invitation to learn more about the craft.

Re:Things I Was Wrong About: Types by TooCreative on Sunday September 27, 2020 @10:58AM (#24607104)
For the example I simply took to a random, recently updated file from Symfony:

https://github.com/symfony/http-client/blob/master/HttpClien...

And shortened it a bit. In the real example, as you can see, there are even more parameters, making it even harder to read.

Re:Things I Was Wrong About: Types by jenscow on Sunday September 27, 2020 @11:43AM (#24607467)
Well, for me it's easier - perhaps because I'm used to reading parameters in type+name pairs.

The data type is right next to the parameter name - and it will be in the pop-up provided by my IDE when I use the function... I don't need to look at the docs or comment (which may not exist).