[lldb-dev] About lldbHost

[Pavel Labath via lldb-dev]

On 15 February 2017 at 18:20, Greg Clayton <gclayton at apple.com> wrote:
>
> On Feb 15, 2017, at 10:14 AM, Zachary Turner <zturner at google.com> wrote:
>
> I think the main improvement that it provides is that you need *something*
> which represents only a path.  Because we use FileSpecs to refer to paths on
> remote machines, and then what does it mean to call Exists or Resolve?  So,
> we could have something like PathSpec and then have FileSpec contain a
> PathSpec, and PathSpec's only purpose would be to know about the grammar of
> a path.
>
>
> Agreed. Are you ok with starting with moving as much stuff from FileSpec
> over into File to start with?
>
>

I don't think File is a good place for at least some of these
functions. If File represents an open file, then at the point where
you already have an open file, it's not really worth asking whether it
exists. What makes more sense is to have an external entity (e.g. a
FileSystem) that you give an abstract pathname (FileSpec) to and it
tells you whether that pathname exists within the context of the
entity. Then you tell that entity "please open me this FileSpec" and
it gives you an object representing an open file (File class). In the
case of remote paths you would not ask the FileSystem class but maybe
the Platform class, but the API would be the same.

Similarly for Resolve: I think of it as an operation that takes an
abstract path and returns another abstract path, resolved within the
context of some external entity.

I can imagine MemoryMapFileContents to live within the File class, as
you have to have the file open to mmap it, but I don't think a
filesystem would be a bad place either.

I don't believe this make code completion harder. E.g. you can do
llvm::sys::fs::<tab> to see all the file manipulation functions in
llvm even though they are free functions.