V Wed, 13 Dec 2017 10:04:24 +0100
Arvin Schnell
On Wed, Dec 13, 2017 at 07:36:19AM +0000, Imobach González Sosa wrote:
On Wed, 2017-12-13 at 00:18 +0100, Ancor Gonzalez Sosa wrote:
This is probably the less useful mail ever, since it just goes over a topic that has been explained over and over and still pops us in almost every single meeting.
Discussing is (usually) fun :)
[..]
Let's do the same in an hypothetical typed Ruby in which there is nothing like nil. Now your find_device_by_name method will raise a NotFound exception instead of returning nil if the device is not there (the approach we use in statically typed languages).
Instead of throwing (and rescuing exceptions) all over the place (an approach I dislike), some typed languages offer a better way to deal with these situations: option types[1].
In a nutshell, an option type represents a value that could (or not) be nil. Lately I've been playing around with Elm and Rust and, in both cases, the compiler will complain if you do not write code to handle the "None" case. You can check some Rust[2] example if you are interested.
And it looks like C++17 already support such a feature (although we are not using it IIRC).
I have that idea in mind (https://trello.com/c/Kjq05SDY/119-use-stdoptional-c17) but C++17 in SLE 15 is experimental.
As a side note (about throwing exceptions), I prefer having "find_by_device_name" and "find_by_device_name!" methods. The former would return 'nil' if a device is not found and the latter would raise an exception.
I always though the function with ! modifies the argument while the one without returns a modified object.
Well, it is only convention and such convention specifies that version with ! is "dangerous" function that e.g. modify object that someone else can use, raise exception if something is missing and so on. It is mainly used to distract between two versions of call ( e.g. similar to some degree to const and non-const versions of method in C++ ).
On the other hand, I've been taking care of YaST incoming bugs these days and I can hardly remember an "internal error" caused by some out- of-control nil value.
I can remember bugs of the kind "undefined method xxx for nilClass".
sadly same kind of errors can happen also in ycp and c++ ( calling something on nil ) and at least for me result is the best from these three ( ycp silently do nothing and c++ segfault ). If we want to prevent this kind of errors, then rust is answer.
And I can also remember bugs where a function name was simply mistyped.
agreed. It is trade-off for dynamic nature of ruby. And for mistyped function names unit tests is currently only answer. In future ruby type inference can help.
ciao Arvin
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org