lua-users home
lua-l archive

Re: [ANN] typecheck 1.1 released

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


On 2017年07月09日 10:05 PM, Gary V. Vaughan wrote:
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,
 }
Ah. Neat.
- 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
That's the thing sandboxes block/filter getmetatable.
--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.

AltStyle によって変換されたページ (->オリジナル) /