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, <[email protected]>
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: [email protected]
To contact the owner, e-mail: [email protected]
