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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4cd85c8656c704b6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-06 03:00:40 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: David95038@aol.com (David Kristola) Newsgroups: comp.lang.ada Subject: Re: Style question: deep inheritance Date: 6 Dec 2002 03:00:40 -0800 Organization: http://groups.google.com/ Message-ID: <5463bc76.0212060300.2f78f4dc@posting.google.com> References: <5463bc76.0212030344.712c30aa@posting.google.com> <3DECAA3A.F3E7BA90@earthlink.net> <7GhH9.54$wk5.1@read3.inet.fi> <3DEDF893.52674CD6@earthlink.net> NNTP-Posting-Host: 63.194.212.92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1039172440 19359 127.0.0.1 (6 Dec 2002 11:00:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 6 Dec 2002 11:00:40 GMT Xref: archiver1.google.com comp.lang.ada:31482 Date: 2002-12-06T11:00:40+00:00 List-Id: Thanks to everyone who replied! > From: Dale Stanbrough > > Another is, of course, possible filename length > restrictions. However I think most O/S's these days > allow filenames of at least 256 chars, which you are > unlikely to reach in a hurry. My development environment (gnat running on MachTen) is happy with long filenames. I first ran into problems when i tried to move the files out of MachTen to my Mac so that i could put them on my web server. I'm using an ancient Mac with an old OS, and 32 characters seems to be the limit. Not a major problem, i "krunched" the filenames as i copied them over. The short names are horrible. > I'ld simply suggest that you use the "use" clause > to reduce the baggage. I've been in the defense industry for many long years. I'm still recovering from the "don't use use" mentality. I'll get there eventually. > From: Marc A. Criley > > The technique I've been using lately to good effect is to employ "use" > clauses that eliminate all but the "bottom" package. E.g., for > SAM.Entities.Things.Portals, I'd have a "use SAM.Entities.Things;", so > then Portals components get referenced as "Portals.Teleport", for > instance. I like that idea. Quite often, packages all up and down the hierarchy are referenced, but just because they are used doesn't mean i can't name the bottom package (for clarity). > Marc A. Criley > Quadrus Corporation > www.quadruscorp.com Quadrus! Hopefully my next employer. I should drop Jan an email and find out what's up. > From: Anders Wirzenius > > A small 2 cents comment which, again, is borrowed from another (at least J-P > Rosen): > The more natural place for the use clause is in the code right before it is > needed, not at the beginning of the package as a tail to the with clause. I have been using this in places, but i still fell uncomfortable about use clauses in general. I've been making exceptions to the "no use" rule for the common standard library packages (like Ada.Text_IO), but that is usually as far as it goes. I'll repent someday. > From: Stephen Leake > > A system should be a simple as possible, but no simpler. Your package > names reflect the actual organization of the system; that's a benefit > :). Things are getting better. I've lost track of how many times i've refactored the code. > Sometimes, you can inherit from a type in a sibling package, rather > than in a child package. So perhaps SAM.Portals is the _right_ package > name in the first place? Perhaps, but something tells me that i want to use child packages. This is the first time i've really worked with tagged types. Portals are Things, but with added special features. They take advantage of many of the classwide subroutines of Things, and even of Entities. Portal_Type is abstract, and adds two abstract subroutines to Things_Type, and adds another two non-abstract routines. Eventually, i think i will have some private routines to support operations carried out by the different classes of portals. Likewise, there will probably be private routines for Things and Entities. Everything in the MUD needs to be read from and written to files. As a self imposed requirement, i want those files to be human readable and modifiable in a text editor. In the end, the lowest level class needs to read/write itself, but there are many common attributes from higher levels. > From: Ted Dennison > > You do realise that you can use relative naming from within the > hierarchy, don't you? For instance, an object inside of > SAM.Entities.Things.Portals can refer to an object in the spec of > SAM.Entities.Things (or either of the other two parents) without any > package notation at all. I have a bad habit of using full names, but i do know that i don't have to. For instance, everything is under SAM, but i still use SAM.Whatever. Within the deep hierarchies, i sometimes use full names, and sometimes don't. Most of the "action" takes place in SAM.Game, which withs in some of the deep hierarchies. I think i'm going to start using local use clauses, or maybe a global use clause. The tagged type names are unique and will direct someone to the right package (Portal_Type is from Portals). SAM itself is a bodiless types/constants/global variables package (pragma preelaborate). It contains the communication types (the simple types used to communicate with ADTs, which in my case is mostly enumerated types). It also contains the root "meta object" abstract tagged type used to work around the withing problem. SAM (Simple Ada MUD) isn't so simple any more. :-( Thanks for all the help! --djk