[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [Proposal] ## operator
- From: Tom N Harris <telliamed@...>
- Date: Mon, 24 Nov 2014 22:32:46 -0500
On Saturday, November 22, 2014 11:28:01 PM Thiago L. wrote:
> On 22/11/14 10:04 PM, Tom N Harris wrote:
> > So what you're really saying is if you want to track the number of items
> > in a table, the best way is to code your own item-counting class using
> > metamethods.
> Doesn't solve the problem for arbitrary input.
Then the problem is overloading plain tables for uses beyond its intrinsic
contract. You're asking for a specific policy (items must be countable) but
want to accept tables that don't promise that policy. If you need countable
tables, then only accept countable tables. Or convert uncounted tables to
countable tables when encountered, or fast-path countable tables but fall back
to slow iteration of uncountable tables.
That's what the comparison to Java elucidates. Advanced behavior comes about
by creating classes. In Java they're necessary and unavoidable, so you put
needed policy in methods without giving it a second thought. But Lua classes
are optional so it's easy to overlook when a class, or something class-like,
would be prudent. Java doesn't have a built-in associative array; it's
implemented as a class. Lua doesn't have a built-in countable container; it
must be implemented with metamethods.
Saying "but what do I do if the user passes a plain table to my Lua function?"
is like saying "but what do I do if the user passes a plain Array to my Java
function?" except you're told explicitly what happens by the type system.
--
tom <telliamed@whoopdedo.org>