Mailinglist Archive: yast-devel (87 mails)

< Previous Next >
Re: [yast-devel] Feedback needed! Hack Week project to re-define storage-ng API
On 02/24/2017 01:57 PM, Josef Reidinger wrote:
On Fri, 24 Feb 2017 13:51:42 +0100
Arvin Schnell <aschnell@xxxxxxxx> wrote:

On Fri, Feb 24, 2017 at 01:34:31PM +0100, Josef Reidinger wrote:
On Fri, 24 Feb 2017 10:58:19 +0100
Arvin Schnell <aschnell@xxxxxxxx> wrote:

On Fri, Feb 24, 2017 at 10:37:24AM +0100, Josef Reidinger wrote:

Nil instead of exceptions

make sense for me, another option that make sense for me is
NullObject, that allows some introspection and e.g. better
writting to log.

Exceptions come with introspection and logging.

ciao Arvin

We also discussed it in past and now with seeing that I need to
rescue around every call for valid storage setup in bootloader, I
found it even more annoying.

You don't have to. E.g. instead of calling
'partition.get_filesystem()' and catching an exception you can
also query 'partition.has_filesystem()' beforehand. The
programming style is up to you.

ciao Arvin

OK, I do not know about it.

Ancor what was reason to not use this kind in bootloader and
yast-storage-ng instead of bunch of rescues?

The reason is that some of those methods (like has_partition_table) were
not there initially, they were added on demand.

Defining an extra method for every relationship we want to have in our
model is just duplicating the existing and standard Ruby mechanism for
that (returning nil).

Assume there is always a "has_xxx" method to do the check in advance.
There are still many situations in which that is way less practical than
returning nil.

For example, something as simple as this with the typical Ruby behavior
(returning nil)

def compare_fs(partition1, partition2)
partition1.filesystem == partition2.filesystem

With the current approach of rescuing exceptions or using the check
method in advance (assuming that particular check method exist).

def compare_fs(partition1, partition2)
if partition1.has_filesystem
if partition2.has_filesystem
partition1.filesystem == partition2.filesystem

The same problem of checking the value of several attributes can be
generalized. Something like this would be quite common in Ruby (and is,
in fact, the principle of many RSpec matchers that we cannot currently use).

def equivalent?(object1, object2, attributes = [])
attributes.each do |attr|
return false if object1.send(attr) != object2.send(attr)

That will crash very easily and most ruby developers wouldn't have
expected because disk.partition_table or partition.filesystem just look
like attributes.

The behavior of the methods when returning a value that is not set
should be uniform. If checking for a not-set integer or string typically
returns nil, checking for a not-set filesystem should do the same. It
must not be different and raise a very particular kind of exception just
for some returned types.

Ancor González Sosa
YaST Team at SUSE Linux GmbH
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups