It took me until just now to read that entire discussion.
On 24.02.2017 16:51, Ancor Gonzalez Sosa wrote:
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
Yes, it is worth it. I like the approach.
It's even harder if you keep moving between all the different worlds we have
(and that we will have to keep and maintain until end of life for SLE-12
which is far away):
- The yast-storage-ng Ruby world
- The libstorage-ng C++ world
- The legacy yast-storage Ruby (converted from YCP) world
- The legacy libstorage C++ world
Changing back and forth between them (as I constantly do) keeps confusing the
hell out of me, so I welcome every little bit of more consistency.
Agreed, Ancor's approach introduces yet another API that is only loosely
connected to the libstorage-ng C++ API. That is a downside, agreed. But then,
we already have a lot of those things all over the place:
- member variable assignment and direct use in Ruby rather than the C++
getters and setters:
obj.var = 42 rather than obj.set_var( 42 )
obj.var rather than obj.get_var()
- automagical search and replace for C++ predicates
obj.foo? rather than obj.is_foo()
- Ruby refinements at certain places
- Convenience classes in Ruby on top of the libstorage C++ API that have no
counterpart there
So, for me it's completely separate worlds already, so we might as well go
all the way and finally get it consistent.
That would also add the benefit that we know where to look for documentation
since the new Ruby wrapper classes hopefully come with it.
Kind regards
--
Stefan Hundhammer <[email protected]>
YaST Developer
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
