Re: [ANN] Penlight Libraries, First release

[Mark Hamburg <mark@...>]

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

> 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!

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

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.

Mark