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.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,577df5d4a0e88785 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-16 03:50:04 PST Path: supernews.google.com!sn-xit-02!supernews.com!216.227.56.88.MISMATCH!telocity-west!TELOCITY!cyclone2.usenetserver.com!news-out.usenetserver.com!feed2.onemain.com!feed1.onemain.com!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: Bad coding standards Date: Sat, 16 Dec 2000 11:36:07 GMT Organization: Deja.com Message-ID: <91fk38$nnu$1@nnrp1.deja.com> References: <910u3p$v9j$1@nnrp1.deja.com> <3A3445A8.8FC404D5@acm.org> <912ut9$fga$1@nnrp1.deja.com> <3A35AFFF.CA2BA2F9@acm.org> <916gfk$e07$1@nnrp1.deja.com> <916n66$j8c$1@nnrp1.deja.com> <3A376D69.A420D711@earthlink.net> <131220001555268634%emery@mitre.org> <1elo8l3.coy4nxb5upaqN%claveman@inetworld.net> <3A3A8272.30052FAD@mtws.visicom.com> NNTP-Posting-Host: 205.232.38.41 X-Article-Creation-Date: Sat Dec 16 11:36:07 2000 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U) X-Http-Proxy: 1.0 x71.deja.com:80 (Squid/1.1.22) for client 205.232.38.41 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:3200 Date: 2000-12-16T11:36:07+00:00 List-Id: In article <3A3A8272.30052FAD@mtws.visicom.com>, Wayne Lydecker wrote: > What would be nifty would be to allow a package > spec define its own "approved" renames of the > package that other packages would be allowed to > use. I'm sure I'll hear immediately why it's not > a good idea though ;-) So let me get this right, you are going to create a long package name and a short package name. The only purpose of the long package name is so that people have to include a renames of the short package name to the long package name in every single client, and they must do it consistently. This seems extraordinarily convoluted. Why not call the package by the short name to start with, and then include appropriate documentation in the package with long names and whatever else you want. The only function of the long name in practice in your scheme will be to act as incomplete documentation (incomplete because names alone never substitute for full documentation) in clients. But even decrepit environments can easily locate the file for a package given the name of the package, so it is trivial for someone to lookup the details on a package that they don't recognize from the short name. One other advantage of using short names for packages is that in debugging it means that you have to type less junk. Sent via Deja.com http://www.deja.com/