Re: {SPAM?} Re: sunday afternoon whishlist

[HyperHacker <hyperhacker@...>]

On Sun, May 9, 2010 at 17:02, Andre Leiradella
<aleirade@sct.microlink.com.br> wrote:
> On 09/05/2010 19:56, HyperHacker wrote:
>>
>> On Sun, May 9, 2010 at 16:33, Henk Boom<henk@henk.ca>  wrote:
>>
>>>
>>> On 9 May 2010 11:36, Klaus Ripke<paul-lua@malete.org>  wrote:
>>>
>>>>
>>>> Could indexing anything but a table, or at least indexing nil,
>>>> return nil instead of throwing an error?
>>>> I don't see why x.z conveniently gives nil, if there is no z in x,
>>>> but x.y.z requires an extra check for x.y .
>>>> This makes working with structures with lots of optional parts pretty
>>>> tedious - and if it's external input, basically everything is optional.
>>>>
>>>> Really I'd love to see nil behave like an empty value of
>>>> the expected type most of the time, Perl style.
>>>>
>>>
>>> I have to say that nil.abc (and nil(abc), and nil + 1) throwing an error
>>> is
>>> how many of my bugs are caught.
>>>     henk
>>>
>>
>> Thus why I say it should probably print some type of warning. It's not
>> something that should be relied on, but the program shouldn't crash
>> just because Config.Foo.Bar.Something doesn't  exist in the file, and
>> checking for it beforehand adds a heck of a lot of code and
>> complexity.
>>
>>
>
> Use metatables. Accessing a key from any type which doesn't have a metatable
> for it besides a table is an error.
>
> Cheers,
>
> Andre
>

That's what I've been doing; the question is should nil have a
metatable to make __index return nil (and perhaps print a warning)?

-- 
Sent from my toaster.