On Tue, 13 Oct 2015 10:43:09 +0200
Arvin Schnell
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.
agreed. It should be what kind you search for. So it is better to have something like search_filesystem
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
above solve it. .
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)?
Difference is that it should define Kind and not Target object. Basically with find_by_xxx we are back in target_map times.
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.
Basically for plugins the best design is to have good concept base class like filesystem, container that have methods that allows them to connect to rest of graph In general I think we should follow already know principles of good OO design like open/closed principle https://en.wikipedia.org/wiki/Open/closed_principle , SOLID or KISS Josef
ciao Arvin
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org