Re: Empty? No. Array? No. Has? Yes.

[Tim Hill <drtimhill@...>]

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 :)

--Tim


On Jul 5, 2013, at 1:03 PM, Javier Guerra Giraldez <javier@guerrag.com> wrote:

> On Fri, Jul 5, 2013 at 2:40 PM, Tim Hill <drtimhill@gmail.com> 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
>