On 17.9.2013 15:47, Jiří Zárevúcky wrote: > On 17 September 2013 15:37, Jakub Jermar <[email protected] > <mailto:[email protected]>> wrote: > > On 09/17/2013 03:05 PM, Jiří Zárevúcky wrote: > > On 17 September 2013 09:52, Jakub Jermar <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > On 17.9.2013 1:06, Jiří Zárevúcky wrote: > > > Because list_t feels too obscure to me. To me it's much > easier to > > write > > > linked list manipulation in-line, and I think the resulting > code is > > > clearer as well. Note that I did use list_t and > list_foreach() until a > > > few days back, but after recent addition of two more magical > arguments > > > to list_foreach() macro, I just didn't have the energy to go > > figure out > > > how it works. > > > > > > That being said, I would not oppose changing this back to > > list_t... but > > > for this one thing, I am not going to be the one doing the > change. > > > > Why wouldn't you? > > > > > > Two specific reasons why: > > 1) It's macro magic. You use as "arguments" arbitrary words you > generate > > code with. Such stuff IMHO should not be done, unless you really > have no > > other alternative. > > 2) The library types obscure what kind of list it is. You could > just as > > well replace all pointer types in the code base with "void *". > > > > You could do better. For example, mandate that a real "next" > pointer is > > used in the list entry, and let the library check its offset and > operate > > on these pointers. You wouldn't need list_t or link_t, you would > instead > > use what they really mean. Instead of using magical macro to retrieve > > entry from a link, you can have the library function return void > pointer > > to the entry, which in C casts to any pointer implicitly. Easier > to use, > > easier to understand, cleaner interface. > > Let me remind you that we are not solving the linked list implementation > problem, but the problem of merging your file system related changes. > Just reuse the common library code, do not invent your own. If you feel > like improving the generic linked list implementation afterwards, you > are welcome. But please, no separate linked list implementations. > > > In the branch, I am not trying to solve the linked list implementation > problem. I just do not use it. It offends my sensibilities. As I said, > if you want, make the change yourself, but I will not make it, as a > statement of disagreement with the use of the library as it is now. You > can either keep arguing about it, or you can just write the change and > send me a patch, which I will promptly apply.
Hm, I am afraid it does not work like that. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
