Re: [ANN] Microlight (was Re: paving cowpaths with libraries)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] Microlight (was Re: paving cowpaths with libraries)
- From: steve donovan <steve.j.donovan@...>
- Date: 2012年2月21日 09:04:51 +0200
On Tue, Feb 21, 2012 at 2:46 AM, Jay Carlson <nop@nop.com> wrote:
> path with LOM (well, it was lxptree at the time). Because I was going
> to be working with code I didn't control, I realized all of my public
> functions would have to rewrap their arguments, and in that particular
> case, deep-rewrap them. And hope nobody else had their own enhanced
> list-like things.
Very true, which is why I respectfully disagree with Dirk that all ml
list-like functions should live in a List class. The original
functions must all be available to fit with other coding styles and
code bases.
> Speaking of guilt-by-naming, I was wondering if the class stuff ought
> to have explicitly-ml naming, like mlclass().
Here I'm with Dirk: ml.class is distinct enough.
> OK, of all of them I suppose that's the least objectionable. If you
> ever use it in a loop you'll be really sorry though, since it can't
> really mutate L1, right?
That's true. It's a nice notation, but not a very efficient one.
BTW, #s is (a) unavoidably O(N) [1] and (b) only works for 5.2. So
perhaps we need count_keys() as well.
steve d.
[1] OK, we can imagine an implementation that tracks the size, but
then sets are no longer simple tables. It's best to keep the
bog-simple implementation and warn people about cardinality
operations.