Re: parser hacking: conditional fields

[Hadriel Kaplan <HKaplan@...>]

As long as it doesn't preclude a '?' from someday being a ternary like C. (I know, wishful thinking! :)

Some things for you to try when you've made the ? change:

config = { color = false, user = { color = 'white' } }
print( config?.user?.color? ) --> should print white
print( config.color? )  --> should print false not nil

settings = { config.admin? }
print(#settings) --> arguably should be 0 not 1

-hadriel


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

> Here's what I'm currently planning:
> 
> '?' is the "Safe Navigator Operator" -- a piece of syntax sugar that converts: 
>    expr? to (expr or _SAFE)
> 
> _SAFE, meanwhile, is the second upvalue placed inside any new chunk.  It's initial value is a unique userdata with a metatable that defines __call, __pairs, __ipairs, __index, and __newindex as nullops.  
> 
> And that's it.
> 
>    object.glow?()
> 
> will cause object to glow if it has a glow function defined.
> 
>    object.clock?.current_time = time()
> 
> sets the current time of object's clock, if it has a clock.
> 
>    object.name?:sub(1,3)
> 
> returns the first 3 characters of object's name, if object has a name.
> 
>    for k,v in pairs(object.table?) do
> 
> iterates though the members of object's table, if it has one 
> 
> The semantics are such that you can easily change the default behavior from a nullop to printing a non-breaking warning --  just define:
> 
>   local _SAFE = setmetatable({},{_index=function(...) print_warning(..) end})
> 
> The general version would be slightly slower than the patch I originally posted, and it would impose some slight memory costs.  But my hunch is that in virtually all situations, those additional costs would be negligible.  Of course, I have yet to code anything up, so, there may be some big drawback or complication that I'm missing.  But at the moment, it's looking like a hugely promising Saturday afternoon project :)
> 
> -Sven