Mailinglist Archive: yast-devel (31 mails)

< Previous Next >
Re: [yast-devel] Again: 98% of "undefined method" errors have nothing to do with static typing
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Wed, 13 Dec 2017 10:27:36 +0100
  • Message-id: <20171213102736.252993a5@linux-vvcf.privatesite>
V Wed, 13 Dec 2017 10:04:24 +0100
Arvin Schnell <aschnell@xxxxxxxx> 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
(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
( 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

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

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

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >