lua-users home
lua-l archive

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

The syntax mod only transforms the constraints into 'assert.*()' calls. You can either override 'assert.table' with your own function, or use another name.

The sample case you mentioned would be covered roughly by (in a hurry, but gives the point):

local function callable( v, field )
	if type(v) == "table" and type(v[field])=="function" then
		return true
		local mt= getmetatable(v)
		if mt.__index and type(v[field])=="function" then
			return true

assert.select_callable= function( v )
	assert( callable( v, "select" ), "No .select function", 2 )
	return v

That code should be somewhere in your app prior to using the ': select_callable' constraint.

There could be more factory support for making such custom asserts easier, but these are the rough edges that will be covered during the spring. Anything is already possible. :)

Happy weekend!

Tomas Guisasola Gorham kirjoitti 29.2.2008 kello 14:09:

On Fri, 29 Feb 2008, steve donovan wrote:
On Thu, Feb 28, 2008 at 9:16 PM, Asko Kauppi <> wrote:
local function mydear( t :string_or_table, i :int, j : [int], n :
[number] )
           : string, table, [int]
               ...function body with returns...

Nice notation!  I was thinking about this general problem the other
day: how does one explcitly specify type in a dynamic language? The
idea was that types are objects, and one builds them up with
   string_or_table = choice(String,Table)
   string_or_nil = choice(String,Nil)
   Location = choice({X=Double,Y=Double},{Double,Double})
	I like that syntax either, but I have some doubts :-)
	Could you accept a proxy table instead of the real table?
How would you specify that?  How would you specify properties of
objects?  An example of what I am looking for is:

function get_status (db, id)
	local cond = "id="" AND estado_retorno is not null"
	return db:select ("status", "processo", cond)()

	How would you specify that you can call db's select?
I am not interested in the real type of db: it could be a userdata
or a table, and in this case it could have the field select or it
could have a metatable with a __index metamethod; also, the select
object could be a function or a "callable" object...  How would you
manage that?
	I am not sure if we should check the _type_ or the operations
we want.  In my case, I only care about being a callable
object.  One might argue that I would have to check its arguments,
but I would delegate it for the call itself.