From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7ee10ec601726fbf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-12 09:07:35 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!news-out.visi.com!hermes.visi.com!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3BC5D730.DA950CC7@boeing.com> <9q4pa7$1ad$1@nh.pace.co.uk> <3BC6ACC8.23EF21BC@free.fr> <3BC71F54.1FFE78FA@boeing.com> <1KGx7.26476$ev2.35117@www.newsranger.com> <3BC7AD82.2A0CCCD4@acm.org> <9qhiqr$af0$1@nh.pace.co.uk> <1nDC7.180$6S7.92255364@newssvr11.news.prodigy.com> <9rjsak$bp3$1@nh.pace.co.uk> <9rmhb9$o1b$1@nh.pace.co.uk> <3BDEF0FE.B55FED9E@san.rr.com> <9rmuqi$es$1@nh.pace.co.uk> <3BDF1F13.4B99361C@san.rr.com> <9rnbtv$5i4$1@nh.pace.co.uk> <3BDF8C59.5020108@mail.com> <9rp9bk$6m9$1@nh.pace.co.uk> <9rrtkt$bum$1@nh.pace.co.uk> <9sml2i$q9b$1@news.huji.ac.il> Subject: Re: why not Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Mon, 12 Nov 2001 12:07:32 EST Organization: http://www.newsranger.com Date: Mon, 12 Nov 2001 17:07:32 GMT Xref: archiver1.google.com comp.lang.ada:16341 Date: 2001-11-12T17:07:32+00:00 List-Id: 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.