On 08/08/2016 12:08 PM, Ancor Gonzalez Sosa wrote:
On 08/08/2016 12:00 PM, Arvin Schnell wrote:
On Mon, Aug 08, 2016 at 10:17:56AM +0200, Ancor Gonzalez Sosa wrote:
On 08/08/2016 10:11 AM, Imobach González Sosa wrote:
Hi all,
AFAIK, you're using refinements in libstorage-ng so maybe some of you are interested in this short article: 'The Pros and Cons of Ruby Refinements'[1].
We are using it because libstorage-ng-ruby performs strict type checking (it's a binding for C++, so it makes sense). That kills duck typing and makes quite hard to use forwarders, decorators and other usual Ruby techniques. Refinements allows us to decorate classes coming from libstorage-ng without introducing other types.
You also refine standard ruby classes, e.g. Fixnum and Float in size_casts.rb.
Having looked at some other refinements I must say that I don't consider them to be good. E.g. you extend 'Partition' with 'uuid' and 'label' that provide the UUID and label from the filesystem on the partition, see partition_attributes.rb. This will cause problems if the 'Partition' object should ever get a uuid or label function, which is possible since partitions on GPT have these attributes (putting aside label/name and UUID/GUID nitpicking).
As yardoc documentation states, these three refinements are only used to make RSpec tests more readable: PartitionAttributes, SizeCasts, TestDevicegraph.
Those are exactly the refinements you find "not good". And you are right :-), they are there just for usage in RSpec, not in "real" code.
Should we move then to a specific namespace to make it more obvious? Something like Y2Storage::Refinements::Test::PartitionAttributes instead of Y2Storage::Refinements::PartitionAttributes -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org