Re: [ANN] Penlight Libraries, First release

[steve donovan <steve.j.donovan@...>]

On Wed, May 13, 2009 at 6:40 AM, Mark Hamburg <mark@grubmah.com> 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!

What is happening is that we're getting cross-talk from another
language, hence the importance of finding Lua terms and distinguishing
them from Python terms.  The List interface is copied from the Python
docs, with less semantic sugar. I originally defined calling a list as
meaning slicing, so that L(2,-2) was the same as L:slice(2,-2), but
this kind of operator overloading leads to trouble and weird errors.
To be more luaish, maybe that should be L:sub(2,-2), since it behaves
much the same way.

> 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
> hassle.

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.

steve d.