On 02/24/2017 02:43 AM, Ancor Gonzalez Sosa wrote:
On 02/23/2017 09:31 PM, Arvin Schnell wrote:
On Thu, Feb 23, 2017 at 05:45:48PM +0100, Ancor Gonzalez Sosa wrote:
My Hack Week project is in that state in which all the important parts work and now it's time to decide if it's worth investing a couple of extra days to finish it all the way down.
Since the ultimate goal is to change how YaST interacts with storage-ng, I would need the opinion of as many YaST developers as possible.
So please, please, please, take a look to this and give your opinion. https://github.com/yast/yast-storage-ng/pull/169
So let's me try to redirect this thread before it becomes a re-edition of the exceptions vs nil one. Don't let one or two single controversial points ruin the full discussion[*]. My proposal is to avoid exposing the libstorage API all along YaST because I consider that exposure to be negative in the long run. Let's focus only in the less controversial points of that reasoning. - Constantly performing downcasts in the Ruby code. I believe we can agree that's the less Rubyist thing ever. - Exposing (SWIG/C++) artifacts, like strictly-typed vectors instead of Ruby-style collections, all along YaST. - Quite hard to add YaST-oriented logic on top. At this point there is already quite some extra logic we have needed to add, using/inventing some workarounds to make that possible (refinements, monkey-patching and more). - Workarounds needed when using standard Ruby tools like RSpec, caused by the fact that we don't do things in the standard Ruby way. I'm not discussing whether duck-typing is better than strict type-checking or whether enums and exceptions are better mechanisms than classes and nil. I'm just saying than doing things in a different way that the whole Ruby ecosystem is constantly causing extra work on our side[*]. - Mixing bytes (Fixnum) with Y2Storage::DiskSize objects.
The most important question is - do you prefer the proposed approach and API* or do you prefer to continue accessing directly to libstorage-ng from YaST?
For me it will make programming in Ruby more difficult since I have to know two APIs (already mentioned in doc/design-decisions.md).
That's a valid point that affects those who know/develop the libstorage API and, in addition, has to develop Ruby parts of YaST (i.e. the S subteam).
So far, this is the only clear argument raised against adding a Ruby layer between libstorage-ng-ruby and the rest of YaST. The rest of the thread has "focused" on discussing one or two particular points of the initially proposed API[*]. So I want to leave those controversial points out of the discussion and focus again in the main question. THE_ULTIMATE_QUESTION << Is it worth introducing that extra layer in order to fix the above-mentioned problems (that we have been suffering for some time) at the cost of forcing the S subteam members to live with two versions of the API in their heads? EOF_ULTIMATE_QUESTION Again, this is a question for the whole YaST team. So please, don't get scared by the amount of mails in the thread discussing small API design details and give your opinion on the main topic. Cheers. [*] All those discussions (nil vs exceptions, enums vs classes) has already proved to be useless in the past regarding the goal of reaching consensus, so we should stop them. But IMHO they have proved something. That there are two clearly defined sides with two clearly defined opinions: developers with a Ruby background vs developers with a C++ background. We will never reach a full agreement on which approaches are better for each controversial point. But using the Ruby approach in the Ruby code and the C++ approach in the C++ one looks to me like the only way to avoid discussing the same over and over. -- 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