On Fri, Feb 14, 2014 at 9:11 PM, Ben Langmuir <[email protected]> wrote:
> > On Feb 14, 2014, at 11:10 AM, Manuel Klimek <[email protected]> wrote: > > On Fri, Feb 14, 2014 at 7:56 PM, Argyrios Kyrtzidis > <[email protected]>wrote: > >> >> On Feb 14, 2014, at 10:49 AM, Ben Langmuir <[email protected]> wrote: >> >> > >> > On Feb 14, 2014, at 10:14 AM, Rafael Espíndola < >> [email protected]> wrote: >> > >> >>> There is no significant difference on the client side (instead of >> calling a >> >>> method on the AFS, it calls a method on the FileDescriptor), it may >> simplify >> >>> a bit some functions to just accept a FileDescriptor if they only >> need such >> >>> a thing (instead of always passing an AFS + FD), and the multiplex >> >>> implementation becomes simpler. >> >> >> >> The only issue I have with it is that code using the virtual fs then >> >> becomes quiet a bit different from code that is not using it. Code not >> >> using it has a FD that is a simple POD that is copied by value. Code >> >> using the virtual fs has a much more complex object that needs to be >> >> passed by pointer. >> > >> > I felt the same way originally, but these are both cases of passing by >> reference since the int is just a handle to a more complex object inside >> the operating system :) The syntax of method calls is obviously very >> different though. >> > >> >> >> >> A filesystem could even use a virtual FD implementation if it wanted >> >> to. Just make the FD it receives an index into a table. That way using >> >> a virtual file per file object is an implementation detail of that >> >> file system. >> >> >> >> In the end, I guess it is a question of preference. Since I have no >> >> better objections than "it looks odd", it is fine to go that way if >> >> people actually using the feature prefer it. Maybe then just call it a >> >> FileObject instead of a FileDescriptor to avoid confusion with the >> >> simple ints we are used to? >> > >> > Good point, any objections to just calling it ‘File’? >> >> This seems too generic, maybe ‘AbstractFile’ ? >> > > When we are at naming, I'll take the liberty to make a very different > proposal: > File, FileSystem for the interfaces, LocalFile / LocalFileSystem instead > of RealFileSystem for the standard implementation. I personally dislike > Abstract or Interface in the names, as it distracts from the rest of the > name (but I fully understand that this is more taste than a real concern ;) > > > The one think I liked about Abstract is it warns you not to assume this is > the real file system, so I’ll use a namespace ‘vfs’. I dislike Local, as > it implies ‘not over a network file system’ to me. > Yea, I can see why you dislike it - I don't have a much better name, and Real doesn't sound too bad (I guess most people would intuitively consider it "the file system of the current OS", so it seems fine). > Here’s what I now hate the least: > > namespace vfs { // replace Abstract > class Status; // hoist to save typing > class File; > class FileSystem; > class RealFile; > class RealFileSystem; > } > > Any *strong* objections? > I like it. > > Ben > > > >> >> > >> > Ben >> > >> >> >> >> Cheers, >> >> Rafael >> > >> > >> > >> > _______________________________________________ >> > cfe-commits mailing list >> > [email protected] >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
