[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Empty? No. Array? No. Has? Yes.
- From: Tim Hill <drtimhill@...>
- Date: Fri, 5 Jul 2013 14:34:33 -0700
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 <firstname.lastname@example.org> wrote:
> On Fri, Jul 5, 2013 at 2:40 PM, Tim Hill <email@example.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.