Page MenuHomePhabricator

[CommandInterpreter] Implement UserCommandExists
AbandonedPublic

Authored by wallace on Apr 6 2020, 12:57 PM.

Details

Summary

I don't have an immediate use for this, but I had already implemented
it, so I better make a diff for this.

Diff Detail

Event Timeline

wallace created this revision.Apr 6 2020, 12:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2020, 12:57 PM
wallace updated this revision to Diff 255455.Apr 6 2020, 12:58 PM

Improve some names

I don't have a hard objection to this, but if we're don't have a use for it, I don't see a need for adding it right now.
Particularly as it sounds weird to me that "user commands" are not a subset of "commands". I know that is how the underlying api works, but the underlying api looks weird to me too. However, that one (unlike the SB version) can be changed whenever we want.

As for the test, the same remarks I made on the other review apply here too.

shafik added a subscriber: shafik.Apr 7 2020, 7:15 AM

I agree, if we don't have an immediate use then I don't think we should add it now.

I think the part of the patch that adds documentation to the existing method should go in (In general all patches that just add documentation have my blanket approval, so please just commit those).

For the additional function: If you just change that CommandExists also checks user commands, I think that seems reasonable to me.

labath added a comment.Apr 7 2020, 8:23 AM

I think the part of the patch that adds documentation to the existing method should go in (In general all patches that just add documentation have my blanket approval, so please just commit those).

About that... the existing practice has been to attach documentation to the python versions of these interfaces (bindings/interface/*.i). Now we started to add it to the c++ headers too. More documentation is always better, but OTOH repetition creates maintenance problems and increases the risk of it going stale. Should choose one of the two interfaces and put all documentation there (and maybe have a way to auto-generate the other one) ?

I think the part of the patch that adds documentation to the existing method should go in (In general all patches that just add documentation have my blanket approval, so please just commit those).

About that... the existing practice has been to attach documentation to the python versions of these interfaces (bindings/interface/*.i). Now we started to add it to the c++ headers too. More documentation is always better, but OTOH repetition creates maintenance problems and increases the risk of it going stale. Should choose one of the two interfaces and put all documentation there (and maybe have a way to auto-generate the other one) ?

We need to keep the documentation in the interface files, that's what produces the python and online doc help. That's where the vast majority of users of the API will go to find help for it. But the C++ docs do go into the C++ API docs on the website so they also have some (if not as much) value. Having a way to salt one from the other would be ideal, though sometimes the Python API needs a little extra color so this isn't entirely trivial.

wallace abandoned this revision.Apr 7 2020, 11:51 AM

Will revisit it whenever I need it