Add KeywordArgs and Optional contracts

[waterlink]

Fixes #131

Allows to do this:

Contract OptHash[nfiles: Opt[Nat], mfiles: Nat] => ArrayOf[String]
def list(nfiles: 10, mfiles:)
  []
end

# both of these work as expected
list(nfiles: 4, mfiles: 77)
list(mfiles: 77)

# and this will fail with contract error as expected as opposed to `Maybe[Nat]` solution
list(mfiles: 77, nfiles: nil)

Contract names are subject to discussion.

[nixpulvis]

I'd call the contract Options personally.

[waterlink]

@nixpulvis thought about that too, but the chance that the user will have the Options class in their domain is much higher (just my gut feeling, maybe not)

[nixpulvis]

Yea, I actually hit this with existing contracts pretty often anyway. I think the real solution is namespacing these contracts under something like C::Options.

[waterlink]

So how about KeywordArgs name then? WDYT?
On May 19, 2015 8:38 PM, "Nathan Lilienthal" [email protected]
wrote:

Yea, I actually hit this with existing contracts pretty often anyway. I
think the real solution is namespacing these contracts under something like
C::Options.

—
Reply to this email directly or view it on GitHub
#151 (comment)
.

[alex-fedorov]

/cc @egonSchiele @sfcgeorge

[egonSchiele]

Just before this ContractError, can you add a line that calls the connect function that will throw the related ContractError, and make it obvious that we are not passing in a value for port?

[egonSchiele]

Left comments, looks good otherwise. 👍 for updating the tutorial. KeywordArgs sounds better to me since that reflects where this contract will be used..

[alex-fedorov]

@egonSchiele Addressed.

Plus renamed both contracts to KeywordArgs[ ..a-hash.. ] and Optional[ ..a-contract.. ].

[egonSchiele]

Thanks!

[sfcgeorge]

Nice!

[gsinclair]

Excellent!

If we're discussing names, my choice is NamedArgs and Opt. I think brevity is a good aim: contract specs can get quite long.

[egonSchiele]

Hey @gsinclair, we already merged this as KeywordArgs.