lua-users home
lua-l archive

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

Yes I agree, as Roberto correctly pointed out you have a gradual deterioration in "empty" until you add a new one .. something I was aware of when I made the original post. OTOH, every language "feature" can be abused in some way or other, but that doesn't make it a bad feature. Even simple integers are subject to abuse :)


On Jul 5, 2013, at 1:03 PM, Javier Guerra Giraldez <> wrote:

> On Fri, Jul 5, 2013 at 2:40 PM, Tim Hill <> wrote:
>> This worked better for me than special array properties (table.has() etc),
>> as I could also pass "empty" as a function argument/return value.
> this is the problem:  it's quite easy to define private "empty" value
> and be assured that no other module would collide with it by accident,
> _but_ if you simply return it to signal emptiness, then it's no longer
> private.  other places have to use it, then you have to assure wide
> agreement on what "empty" value to use.  (and very soon you need a new
> "really empty" value, and then a third, and so on).
> if you keep the private "empty" really private, using it _only_ to
> store emptiness, but a different "out of band" way to signal it
> (.has(), .delete(), etc), then there's no need to standardize on which
> "empty" is used on every module, nor any "meta emptiness" escalation,
> nor any need to add new types to the language.
> --
> Javier