Re: parser hacking: conditional fields

[Hadriel Kaplan <HKaplan@...>]

On Mar 3, 2013, at 1:28 PM, Sven Olsen <sven2718@gmail.com> wrote:

print( config.color? )  --> should print false not nil

This is the big potential drawback I can see for my _SAFE approach.  While the syntax is shared with CoffeeScript's existential operator, the semantics are different.  As I'm defining it, ? is a utility for safe table navigation -- it shouldn't be used to check for existence.  "config.color?" is prettymuch guaranteed to never be nil or false, as it's just shorthand for "(config.color or _SAFE)".

You could have the patch do this:

function __check(expr)

if type(expr)=='boolean' then

return expr

else

return _SAFE

end

end

and convert:

expr? to (expr or __check(expr))

That would also be better because I think I would expect this to yield a real Lua error:

print ( config.color?.style) --> config.color is a boolean false not a table

Because it would cause a real Lua error if config.color == true with your current approach, right?  I think it should behave the same regardless of it being a true or false boolean.

For the other problem of:

print(#settings) --> arguably should be 0 not 1

I don't think that's as big a problem, and likely requires either changing Lua's core to handle '?' properly, or using the nil metatable approach.

But it's likely to cause problems when using your patch.

For example:

settings = { color = config.admin?.color }  --> settings.color = _SAFE userdata now, instead of nil

if settings.color then 

print("D'oh!")  --> we get here because a _SAFE is neither false nor nil

end

-hadriel