lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi Soni,

On 07/07/2017 09:23 PM, Soni L. wrote:


On 2017-07-08 12:45 AM, Gary V. Vaughan wrote:
I am happy to announce release 1.1 of typecheck.

Typecheck's home page is at http://gvvaughan.github.io/typecheck
[[snip]]

Why not pow decorators?

x + argscheck "my_function (int, int) => int" .. f --> runtime error
x + argscheck '...' ^ f --> ok

In any case, both operators are right-associative, which gives proper decorator semantics.

(Also please tell me you felt inspired by my own libs? ^-^ [1][2])

I did see the announcements, but the decorator syntax was a contributed
patch.  Until that point I was using decorator functions:

  x + argscheck('my_function (int, int) => int', f)

However, even now I'm not convinced of the utility of inline argscheck
calls.  Adding the decorators to a module export table seems much more
manageable to me:

   return {
      fname = argscheck 'fname (int, int) => int' .. fname,
   }

- New `check` method for ensuring that a single value matches a given type specifier.

- New "functor" type specifier for matching objects with a `__call` metamethod - note, most `std.object` derived types will match successfully against the "functor" specifier.

- New "callable" type specifier for matching both objects with a `__call` metamethod, and objects for which Lua `type` returns "function" - note, this is exactly what the "function" specifier used to do.

Does this work in sandboxes?

Sure.  Why wouldn't it?  As long as the __call metamethod is accessible
to the decorator function at call time, it can be used to check the
arguments.

Cheers,
Gary