<div dir="ltr">Something that has come up now in a couple of contexts is the re-use of the command objects.<div><br></div><div>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.</div><div><br></div><div>I guess I have a couple of questions:</div><div><br></div><div><ul><li>Is there something that we can do to improve code re-use at this level? Are there requirements for code-level compatibility here?<br></li><li>Is there much interest in making command parsing or command output formats more flexible?  (In one system that I use, we effectively have a tree of commands and can splice in new subcommands very easily, much like the Lisp Machine command line or that of a router. This way, the Objective C runtime could, for example, create a subcommand for "breakpoint set -s" for selector-based breakpoints without this having to be something global.)</li><li>Would it make sense for commands to be more directly implemented using the SB* APIs so that it is clear that everything that commands do can be done without using the lower level APIs?</li></ul><div></div><div><br></div><div>For an example of something that is done in a command that isn't as easily doable via SB* APIs is the use of Args::StringToAddress by various commands, notably "breakpoint set -a". Something like that might be a nice addition to SBTarget or SBAddress perhaps?</div></div><div><br></div><div>Cheers,</div><div><br></div><div> - Bruce</div><div><br></div></div>