Re: why not

[Ted Dennison<dennison@telepath.com>]

In article <9sml2i$q9b$1@news.huji.ac.il>, Ehud Lamm says...
>
>I suggested this design but nobody seemed to really like it.
>At the very least the algorithms should be in a collective child package.
>Many users don't need them, and this helps control the complexity and
>learning curve.

I thought it was a bad idea just because any such child package would have to be
instantiated from the parent package (that's the way generic children work), and
there seemed to be agreement that that was a Bad Thing. Plus the "parent"
package is hardly so big that it requires splitting up.

However, if its a rarely-using thing (advanced users only), perhaps it isn't so
bad to have it somewhere else. Plus Sort is *already* a generic. I'm still not
sure about the advisability of moving Sort though. I don't really see what it
hurts where it is, and I don't like the idea of a lot of single routine child
packages, or of one "extra stuff that you don't need often" child package. (To
me "algorithms" is about as general as "stuff"). I like my packages to have at
least a small amount of weight to them (more than 2 routines or so), and to have
strong cohesion.

In particular, I don't see "Sort" being much more than 10-40 SLOC. I could be
wrong, as no-one's started work on an implementation yet.

What precisely would you propose to include in "Algorithms" (or "stuff")?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.