<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 7:01 PM Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com">jdevlieghere@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Sam,<div><br></div><div><div>Does extending the status with a path sound reasonable? This would work similar to the current Name field, which is controlled by UseExternalName. </div><div><br></div><div>Please let me know what you think.</div><div><br></div><div>Thanks,</div><div>Jonas </div></div></div></blockquote><div><br></div><div>Design-wise, adding a second Name field to Status doesn't seem significantly different than adding a "getOtherName" field to VFS.</div><div>I don't think it's really reasonable to have this in the VFS interfaces, because using it in any way means you're coupled to particular implementations.</div><div><br></div><div>Implementation-wise, it seems the only way to do that would be to add an extra string to Status, and some applications probably keep a lot of Status objects. So it doesn't seem like an improvement vs the VFS method.</div><div><br></div><div>Overall I think if LLDB wants to wants to break abstraction and use the native filesystem sometimes, it should have concrete private implementations with wider interfaces, and bridge to common code by having them implement the VFS interfaces. The contract of VFS may have been "real filesystem with some redirected files", but I don't think it has been for several years, and people rely on this.</div><div><br></div><div>I'm not an owner here though. I don't really know how these decisions get made, and would like to hear more opinions.</div></div></div>