On Thu, Sep 25, 2014 at 10:15 AM, Aaron McCurry <[email protected]> wrote: > On Thu, Sep 25, 2014 at 10:07 AM, Tim Williams <[email protected]> wrote: > >> On Thu, Sep 25, 2014 at 9:37 AM, Aaron McCurry <[email protected]> wrote: >> > Let me try an example: >> > >> > public class YourCommand extends Command implements >> IndexReadCommand<Long> { >> > >> > // Normal command logic here... >> > >> > // Required by default. >> > public void setTable(String table) {...} >> > >> > @OptionalArgument >> > public void setShard(String shard) {...} >> > } >> > >> > I realized it's not that sexy but it should make it very easy for the >> > platform to do argument checking at the controller (or even the client). >> > Also removes the need to annotate all the arguments at the class level. >> > Instead you can annotate/javadoc right on your command. >> > >> > Does this help? >> >> Definitely, thanks. This is far better than the Args approach. So, >> inside a command method (e.g. execute() ) you're guaranteed that >> required props are set and you only need to check optionals? I like >> that we can fail client-side too, and that we can create constructors >> with required stuffs to make it easier. I like it. >> > > If we make required getters and setters then I think we could make default > behavior be required. However what do you think we should do when only one > of the 2 methods are implemented? > > Should we instead make the fields be annotated as required and optional? > Then it's up to the implementor to decide if they want to use getter/setter > methods or constructors etc. We can use reflection to set the fields as > needed. What do you think?
Yeah, annotating the fields seems the most flexible and reliable - and prolly be explicit about both required and optional. I suppose the only thing with fields is that inherited commands could get a little difficult to understand when conflicts of optional/required occur? Thanks, --tim
