lua-users home
lua-l archive

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

My own opinion on the matters arising from 'empty' is already contained
in the Subject field of the post. The rest of this post is a summary of
the century-scoring thread.


Non-constructive parts of the debate:

   1. We've heard all this before.
   2. I prefer to ignore most if not all of your post so that I can get
      in a reply as fast as I can type.
   3. You're not really listening to me. Here is the same stuff again.
   4. This list sucks, I'm leaving.

The problem:

   There are many situations where the programmer, especially the
   newbie programmer, has a reasonable right to expect Lua to be able
   to tell whether a key with no useful value is just a nonsense key
   (probably a typo) or a key that forms part of the logical design
   but has no value just yet.

Example cases:

   Arrays acted on by the table library; database-like tables with
   missing fields.

The non-solution:

   `nil`, though explicitly stored by Lua on the VM stack or inside the
   array part of a table, is also used to indicate a value when there
   is none, and hence does not carry enough information for making that


   Sentinels (i.e. unique Lua objects) to take the place of nils;
   exploiting the __index, __newindex, __pairs, __ipairs and __len
   fields of the metatable.

Criticism of the workarounds:

   The wheel is being reinvented in slightly different ways all the
   time when the underlying problem is still the same.

Suggested extensions to Lua:

   1. A standard sentinel value (called 'empty', 'placeholder' etc)
      maybe even having its own type.
   2. A dedicated implementation of arrays, maybe as a new type, maybe
      as a new library, maybe dependent on non-numeric fields.
   3. New standard functions: 'table.has' to indicate whether a key is
      legal; 'table.delete' to permanently change the legality status
      of a key.

Non-negotiable restriction on any change:

   Full backward compatibility, including validity of the idiom
   t[#t]=nil for shortening a list.

My own suggestion, totally ignored so far:

   Implement 'has' via a new metatable field, whose behaviour depends
   on its type.

   - nil or none: the current behaviour
   - nonnegative integer: value of #tbl, positive numeric keys being
     legal only if in the range 1..#tbl
   - table: a prototype containing legal keys
   - function: a decision procedure for establishing legality


The next few points are comments rather than points already made.

1. Any solution that addresses only arrays does not solve the problem
   identified by the OP.

2. It's a pity there were not more posts along the lines of:

   - This is what we do in our organization.
   - This is how long we've been doing it.
   - This is how our programmers react to our way of doing it.
   - This is the way we implement it.