> On Feb 23, 2015, at 1:13 PM, Zachary Turner <ztur...@google.com> wrote: > > On Mon, Feb 23, 2015 at 12:49 PM, <jing...@apple.com> wrote: > > > On Feb 23, 2015, at 11:43 AM, Bruce Mitchener <bruce.mitche...@gmail.com> > > wrote: > > > > Something that has come up now in a couple of contexts is the re-use of the > > command objects. > > > > I'm working on an alternate user interface which has a richer form of > > output than the current CLI. I'm not able to use some of the existing > > commands due to this. The same is true of someone who might want to do an > > alternate command system with a WinDbg style approach. > > > > I guess I have a couple of questions: > > > > • Is there something that we can do to improve code re-use at this > > level? Are there requirements for code-level compatibility here? > > We aren't guaranteeing anything about lldb_private API's, if that's what you > mean. OTOH, changing the behaviors of commands in the lldb command language > set should be done judiciously if at all. > > FWIW I have some interest in the very long term in providing an alternative > command language. I say "alternative language" because I'm thinking of > something more involved than just adding a few extra commands, or changing > some options. I haven't nailed it down too concretely, so take anything I > say here with a grain of salt, but it would involve being able to switch > languages on the fly with a setting. > > When we talk about "a richer form of output" are we talking about only the > output? Because later you mention having a tree-like structure of commands, > so it sounds like you might also be talking about a different command syntax > or structure as well.
My overall take on this is if you want to provide a command language that has the same pretty simple structure, and unformatted output, that the lldb command language does, then it would be fine to extend the CommandObjects to back more than one parser. If you're getting any more ambitious than this, you'll probably want to re-implement the command functionality (e.g. to provide more structured output, etc.) using the SB API's, and not clog up the current command line code trying to make it serve two masters. Anything that is really complex in the current command set should be pushed into the lldb_private API's and then to the SB API's if it is indeed useful. Note, we try to do this as a cleanup task whenever we come across this sort of thing. So sharing the CommandObject code won't save you all that much work. And it's likely to keep both implementations cleaner. Jim _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
