Hacker News new | past | comments | ask | show | jobs | submit login

Optional parameters are a different thing. Yeah one workaround with the lack of optional parameters are to send nil values, but that's only going to work if the type you want optional is a nil'able type. Plus there's nothing stopping null values from being passed in Python code outside of optional parameters. My point is optional parameters are one reason why null values might creep in but not the cause nor reason for null values.

Plus I personally think if you need an optional parameter then 99% of the time the API is likely designed wrong from the outset (eg maybe you should instead be passing a class). The reason being is that optional parameters aren't always predictable (eg why is this value optional? When do I need to include a value for it?)




You completely missed my point. Both my examples were when a function returned an object, and the caller has no idea whether that object ever null. It has nothing to do with parameters.

For what it's worth, I completely disagree with your point. Optional arguments are there to set default values. Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them in the language.

[0] https://commandcenter.blogspot.com/2014/01/self-referential-...


> You completely missed my point. Both my examples were when a function returned an object, and the caller has no idea whether that object ever null. It has nothing to do with parameters.

Type hints then? I don't write much Python so your point might have be clearer had you provided an example. But even in the case of type hints, it requires the developer to be diligent about setting those hints -- Python will happily plod along without them.

That's actually one of the reasons Python isn't my preferred language. I generally prefer something where typing a lot stricter. But this is personal preference and not a judgement on Python.

> For what it's worth, I completely disagree with your point. Optional arguments are there to set default values.

Default values can be set via constructors. Which then allows you to define far more explicit APIs. For example a method that explicitly sets the optional properties when needed might be called `CreateFooWithOnions()` and that method is aware that `.bar` is required to be set for "Onions". Other methods that know the defaults don't need to be set can leave those optional properties with the default. Thus the developer doesn't have to consider if an optional parameter is required in specific use cases, they instead call the method for their use case that is aware of what optionals are required for that use case.

I went through a phase of using optional parameters in the 90s and as I worked with more contributors, and other projects interfaced with my own APIs, I began to realise that optional parameters aren't self documenting. They're not descriptive. Instead it requires the user to understand what's happening under the hood of the API. So I learned from that and moved away from optional parameters.

> Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them in the language.

That link was from early 2014. Back then methods were only 6 months old (in Go). In fact Rob Pike (and others) tried a lot of things in the early days of Go. Some of those ideas sucked and were never heard from again. And some of the ideas worked and are now part of the core library.

Also the ironic thing here is while the API is called "Option" what Pike is doing is not creating optional parameters but actually creating objects with optional properties. Exactly like I've been describing as the better solution. Albeit Pike's work created a bunch of additional boilerplate and ultimately ends up with something that isn't any more readable. Which is likely why that idiom never made it to Go 1.3 (and beyond).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: