V Wed, 13 Dec 2017 10:04:24 +0100 Arvin Schnell <[email protected]> napsáno:
> 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: [email protected] To contact the owner, e-mail: [email protected]
