> Le 6 avr. 2017 à 16:12, Yaniv Kaul <yk...@redhat.com> a écrit :
> 
> 
> 
> On Thu, Apr 6, 2017 at 4:49 PM, Fabrice Bacchella 
> <fabrice.bacche...@orange.fr <mailto:fabrice.bacche...@orange.fr>> wrote:
> 
>> Le 6 avr. 2017 à 15:32, Yaniv Kaul <yk...@redhat.com 
>> <mailto:yk...@redhat.com>> a écrit :
>> 
>> 
>> 
>> On Thu, Apr 6, 2017 at 3:58 PM, Fabrice Bacchella 
>> <fabrice.bacche...@orange.fr <mailto:fabrice.bacche...@orange.fr>> wrote:
>> Yes I'm starting to understand that thinking about migrating code is 
>> pointless.
>> 
>> The old skd3 code is just good to be thrown away. There is no hope thinking 
>> about "migrating code". And as it's just a thin layer around REST calls, 
>> it's up to us to try to make something usable around that. So I expect a lot 
>> of sweat and tears to adapt my existing code.
>> 
>> Well, yes and no. Yes, it's not smooth, but once you 'get' the idea behind 
>> the v4 API philosophy, it's quite easy to write to (at least in Python).
> 
> An example of code that I'm unhappy to write and that a good sdk should have 
> provided:
> 
> searchfilter = "%s=%s" % (type, value)
> vm = vms_service.list(search= searchfilter)[0]
> 
> instead of :
> vms_service.list(search= {type: value})[0]
> 
> or even better:
> vms_service.get(**{type: value})
> 
> 
> Yes, I see what you mean. 100% more LoC are currently needed vs. your idea ;-)

It's not about the number of LoC, it's about legibility, having code that says 
what's it's doing and doing what it says.
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to