medismailben wrote: > Is part of the goal of this class to extend another platform by being able to > override a built in platform? If so, we might want the script platform class > to be able to specify the name of the platform it wants to extend with a > method. Something like: > > ``` > class ScriptedPlatform: > def extends_platform_name(self): > '''Get the name of the internal platform this class extends.''' > return "iPhoneOS.platform" > def get_platform_name(self): > '''Get the name of this platform.''' > return "iPhoneOS.platform.scripted" > ``` > > Then the script platform python class would instantiate a > `"iPhoneOS.platform"` platform and keep it as an instance variable, then the > ScriptedPlatformPython would check if the python class implements the method > in python, and if it doesn't, it will call through to the > `"iPhoneOS.platform"` platform via its instnace variable. Any methods that > are overridden in the scripted pyton class would take precedence and not call > through to the underlying platform. If a python class doesn't have a `def > extends_platform_name(self):` method, then any methods that aren't there just > return an error of `"unimplemented"`.
Very interesting idea. This is not was I was thinking of while implementing this: `ScriptedPlatform` is meant mostly to mock a new platform to be able to list and "launch" or "attach" to processes (mainly `ScriptedProcess` but nothing should prevent us to launch a `GDBRemote` process or any other kind. I think this is a pretty cool idea, but this PR is already pretty big & intrusive, so I think we should do it as a follow-up, once we've figured out how we could break up platforms like @JDevlieghere explained. I'd also love to hear other people opinion on extending platforms through ScriptedPlatform (cc @labath @jimingham @JDevlieghere ) https://github.com/llvm/llvm-project/pull/99814 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
