On 16.9.2013 13:26, Martin Decky wrote: >> I think both of those would actually be more confusing. Using vfs_ >> prefix for a library that does more than just wrap VFS would be >> equivalent to using ipc_ prefix for the entire async framework. >> Even more so if under the same prefix there are functions with raw >> numerical handle and functions with pointer handle. > > That's a good point. So how about keeping the vfs_ prefix for the really > low-level functions (most of them will probably stay private) and use > some really intuitive object prefix(es) for the intended public API? > > Say file_ for file functions, dir_ for directory functions, etc.? I > know, it's also not perfect, but it's (IMO) better than a cryptic > acronym such as vcl_.
I don't really care about the actual prefix. All of file_*, dir_*, vfs_*, vcl_* are fine with me. >> Right now, I don't know what is the right solution. I will have to first >> implement the stuff that actually uses client-side data, so that we all >> have a clear idea of how the handles are used in different functions. > > Sounds good. Without the actual code the debate is mostly academic, me > fighting for the conservative side and Jiri fighting for the progressive > side :) So perhaps this change could wait for after the merge and we could go in this one particular case back to handles for the sake of the merge? Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
