On Tue, Oct 13, 2015 at 08:55:48AM +0200, Ancor Gonzalez Sosa wrote:
Yes. And it should be fairly easy to implement. But I still wonder about how flexible and future-proof is to keep adding find_by_xx on demand to the API.
More flexible solutions would also be more complex to use for sure. I just wonder if they are worth exploring. One obvious solution (that would need refinement, of course) if having a search object that accepts any number of key-pair filters. The most primitive form just to expose the idea would be something like (in pseudocode):
s = Storage.search(device_graph, "filesystem") s.add_filter("mountpoint", "/") s.first()
1. This API converts compile-time checks to runtime errors, e.g. if you search for a flag that does not exist. 2. It's not type-safe in that the s.first() cannot return a Filesystem object but only a Device and then you need all the manual casts you don't want. 3. The search function must be adapted for every new object and flag. Why is that be better than adding a find_by_xx function (in the class where xx is)?
Or any other idea that can be implemented with a fixed set of classes and methods instead of extending the existing classes with new custom methods over time.
The set of classes is not fixed. On research already people requested to have plugins to support new storage types so any design that has a central search function like above looks inappropriate. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org