On Tue, Oct 13, 2015 at 03:19:45PM +0200, Josef Reidinger wrote: > On Tue, 13 Oct 2015 14:54:40 +0200 > Arvin Schnell <[email protected]> wrote: > > > On Tue, Oct 13, 2015 at 01:05:16PM +0200, Josef Reidinger wrote: > > > On Tue, 13 Oct 2015 11:29:44 +0200 > > > Arvin Schnell <[email protected]> wrote: > > > > > > > On Tue, Oct 13, 2015 at 10:14:03AM +0200, Josef Reidinger wrote: > > > > > > > > > > I'll do more experiments with this as soon as the prototype is > > > > > > easily installable. But looks pretty clear that it would be > > > > > > fairly easy to fix the un-rubism by adding the corresponding > > > > > > methods in the Ruby side in case we decide we are so purist > > > > > > that we cannot live with the current API. :-) So nothing to > > > > > > fix in the libstorage (C++) side. > > > > > > > > > > I agree, that it make sense to have some helpers to have ruby > > > > > bindings more "ruby". > > > > > > > > Just remember that those need documentation and test cases. > > > > > > > > > > >> a) Is device_graph always an object representing the whole > > > > > > >> graph? > > > > > > > > > > > > > > The devicegraph always represents the whole graph. > > > > > > > > > > > > > > > Well, in general I do not like this API before and I also do not > > > > > like it now :) > > > > > It is not object oriented and whats more device_graph is god > > > > > like object. > > > > > > > > Please elaborate this. What do you mean by God like object? A > > > > object that holds all storage objects? > > > > > > Yes, if you have object that hold everything it is not graph, but > > > flat structure. > > > > Sure it's a graph, see > > https://en.wikipedia.org/wiki/Graph_%28mathematics%29, esp. "a > > graph is a [...] pair G = (V, E) comprising a set V of > > vertices [...] together with a set E of edges [...]". > > OK, to be precise graph of objects, not just data.
But the device graph does hold objects and all the storage data is in that objects. Just look at Devicegraph.h and you can see that it is a small class. > > I consider a single search function, as was proposed, as too > > powerful (among other problems already explained). > > Question is if for user is easier to learn and understand powerful > method or powerful object, that have bunch of methods. The design has a many objects with few functions. > > > That is something different. Now you have one object that holds it. > > > so it is like > > > > > > device_graph -> A, B, C, D, E > > > > That is not a graph but just a list of nodes without edges. > > I just want to demonstrate why it is god object and flat desing. > device_graph point to everything. So it is god or big brother :) No, it is not. The device graph does not directly contain all storage data. > Difference is who knows about connection. If graph knows about > connections or nodes. Suppose you have a system with ten empty disks and you represent those not in a graph or list. How can you iterate over all disks? > > In the current prototype the functions can work on all graphs, > > whether it's the "system", the "staging" or "my ideas" graph. > > And is it reusable code? Now all code depends heavily on device_graph. > So if I want reuse some class elsewhere I need big god object like > device_graph. If it is used by smaller classes I know that for > reusability I need implement few abstract classes or in ruby case have > objects that responds to given set of methods. Many functions simply cannot work without more knowledge of the graph. E.g. partition functions need the partition table type, logical volume functions need the name of the volume group, etc. So the objects have a backreference to the graph on purpose. Otherwise you would indeed end up with objects that just hold the storage data and a bunch of floating functions taking as the first two arguments the device graph and object. That sounds like a horrible interface. > > > If I am interested what e.g. device_graph provide me, I can do > > > device_graph.methods which in case passing device_graph everywhere > > > do not should interesting stuff. Also methods is not documented in > > > it and lives elsewhere. > > > > Sorry, I don't understand that. > > My point is that class in object design is encapsulated data and > ability it provides, so for usage you check methods of class. But > device_graph have a lot of methods that lives in different place. Do you look at Array when you want to know that you can do with the Person stored in Array<Person>? The graph is just a container. > > If I get you right you want to replace documentation by > > introspecion. > > In general no. introspection is to get ability of object. Documentation > is to get details of abilities. Introspection is useful when you want > extendable interface. Then I don't understand you. > And thats the point. I think it is wrong if all data is hold by > device_graph. It is not clear for me how extension can extend data if > it is all hold by one class. It is not all in Devicegraph. Look at the class. Look at Filesystem class. Where is the filesystem label and UUID? > And BTW how Storage::Filesystem class holds data to find > mountpoint? > https://github.com/aschnell/libstorage-bgl-eval/blob/master/storage/Devices/Filesystem.cc#L158 > shows that it use data from device graph, which holds all data. No, it uses Devicegraph as a container but the mountpoint is in Filesystem. > I think in general conclusion for me is that I do not like data centric > api with device_graph and we do not agreed on that, so I am interested > also in others opinion. The design is not data centric. The general conclusion for me is that this thread gives no new insight and unless really new ideas come up I will not comment anymore. 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]
