lua-users home
lua-l archive

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

On May 13, 2009, at 12:19 AM, steve donovan wrote:

On Wed, May 13, 2009 at 6:40 AM, Mark Hamburg <> wrote:
remove_value( 2 ) suggests that it removes an item or all items with the
value 2. remove_at( 2 ) is probably better.

Naming is one of the hard things to get right.  Flemming pointed out
that 'remove' conflicts with what we expect from table.remove, that
is, by index. The name  'remove_at' still suggests that it is
expecting an index.  So the search continues!

Sorry. I assumed that it was removing at a particular index, hence my suggestion.

In the past, I've distinguished between mutable types and frozen types with methods for converting between the two, but I'm not sure it's worth the

Yes, making the function explicitly carry that kind of information
leads to clunky identifiers.  The documentation has simply to be very
explicit on this point, much as a dictionary always tells you upfront
whether a verb is transitive or not.  And (as David points out) this
kind of knowledge can be encoded in a generalizable lint tool which
can track potential confusions.

It certainly would be consistent and reassuring if List represented an
immutable type, so all operations returned copies. And mutable
versions could be moved to tablex, so that they were available for
cost-conscious consumers (like reverse).  But then efficient method
chaining becomes harder.

My distinction was that only the mutable types supported editing operations and those all chained. In this case, it was working on geometry, so I had routines like unionWith. The immutable types only supported reading properties. They both supported routines named "mutableCopy" and "frozenCopy". The former always made a copy. The latter would return self if the input was already frozen.

I don't know that it was worth the trouble, however.