[lldb-dev] About lldbHost

[Greg Clayton via lldb-dev]

> On Feb 15, 2017, at 10:37 AM, Pavel Labath <labath at google.com> wrote:
> 
> On 15 February 2017 at 18:20, Greg Clayton <gclayton at apple.com <mailto: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.

My main complaint here is if we have a FileSpec and I want to do some operation on it, I have no idea to look in llvm::sys::fs::....


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170215/47ca3176/attachment-0001.html>