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? Aaron > > Thanks, > --tim >
