labath added a comment. In D68546#1698622 <https://reviews.llvm.org/D68546#1698622>, @lawrence_danna wrote:
> Personally, I think `%extend` is a bit ugly as it increases the difference > between what's in the headers and what's actually in the python bindings, so > I'd rather not do it that way. But I'm not dogmatically opposed to it. Yeah, the %extends are somewhat ugly, but I also find the FileSP overloads in the "public" sections of the SB classes unnerving too, because they are not really public -- no user can actually call them directly in a meaningful way. They are really only meant for the python interface, which sort does sit on the other side of the SB api, but also kind of doesn't. That's the weird part about lldb python support, where python can be embedded *into* lldb, but it also can be sitting *above* it (or both at the same time). I am not really sure what to do about that. I don't suppose there's any way to make the FileSP overloads private? Or maybe they actually should be public, and the actual problem is that there is no way for a c++ user to make use of this functionality, even though it should be able to? Right now, the c++ api is sort of disadvantaged in that one cannot create an SBFile that would redirect to some custom fancy c++ output object. I am not saying you should implement that, but if we assume that such functionality were available do you think it would be possible to implement the python stuff on top of that? In that sense, maybe the FileSP overloads are actually fine, and we can treat them as a placeholder for this hypothetical future functionality? I am sorry if this doesn't make much sense -- that's because I myself am not clear on this matter. But I hope that I at least managed to give you an idea of the things going through my head right now. If you have any thoughts on any of this, I'd like to hear them. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68546/new/ https://reviews.llvm.org/D68546 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
