* Style question: deep inheritance @ 2002-12-03 11:44 David Kristola 2002-12-03 12:55 ` Dale Stanbrough ` (3 more replies) 0 siblings, 4 replies; 9+ messages in thread From: David Kristola @ 2002-12-03 11:44 UTC (permalink / raw) I am working on a MUD in Ada. Inheritance lends itself well to the problem domain, but after a few levels of child types in child packages, i am facing some ridiculously long names. For instance, portals are used to move from place to place. But they are a specialization of inanimate objects (things), which are a specialization of general things (entities), which are a specialization of the parent class (which is used to avoid the withing problem). So, portal specific operations can be found in SAM.Entities.Things.Portals. The three (and counting) specializations of Portals are only referenced once to initialize them and let them register themselves into the system. I could use renames to flatten out the majority of references (package SAM.Portals renames SAM.Entities.Things.Portals;), but you can't inherit from a rename, so the actual children are still deeply nested. The long package names usually mean long file names. This could become a portability problem. I'm interested in how other people have dealt with this problem, or suggestions for how i might deal with it. Thanks, --djk ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-03 11:44 Style question: deep inheritance David Kristola @ 2002-12-03 12:55 ` Dale Stanbrough 2002-12-03 12:56 ` Marc A. Criley ` (2 subsequent siblings) 3 siblings, 0 replies; 9+ messages in thread From: Dale Stanbrough @ 2002-12-03 12:55 UTC (permalink / raw) In article <5463bc76.0212030344.712c30aa@posting.google.com>, David95038@aol.com (David Kristola) wrote: > I am working on a MUD in Ada. Inheritance lends > itself well to the problem domain, but after a few > levels of child types in child packages, i am > facing some ridiculously long names. For > instance, portals are used to move from place to > place. But they are a specialization of inanimate > objects (things), which are a specialization of > general things (entities), which are a > specialization of the parent class (which is used > to avoid the withing problem). So, portal > specific operations can be found in > SAM.Entities.Things.Portals. The three (and > counting) specializations of Portals are only > referenced once to initialize them and let them > register themselves into the system. I could use > renames to flatten out the majority of references > (package SAM.Portals renames > SAM.Entities.Things.Portals;), but you can't > inherit from a rename, so the actual children are > still deeply nested. The long package names > usually mean long file names. This could become a > portability problem. It's a portability problem for a number of reasons. One is that there is no standard for filenames in Ada :-(. 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. If you are using Gnat, then you can "krunch" the filenames down to 8 chars (originally designed for DOS systems). This has the benefit of portability, but the drawback of horrible filenames, and, possibly, name conflicts. I'ld simply suggest that you use the "use" clause to reduce the baggage. Dale ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-03 11:44 Style question: deep inheritance David Kristola 2002-12-03 12:55 ` Dale Stanbrough @ 2002-12-03 12:56 ` Marc A. Criley 2002-12-04 6:56 ` Anders Wirzenius 2002-12-03 14:21 ` Stephen Leake 2002-12-04 19:19 ` Ted Dennison 3 siblings, 1 reply; 9+ messages in thread From: Marc A. Criley @ 2002-12-03 12:56 UTC (permalink / raw) David Kristola wrote: > > I am working on a MUD in Ada. Inheritance lends > itself well to the problem domain, but after a few > levels of child types in child packages, i am > facing some ridiculously long names. For > instance, portals are used to move from place to > place. But they are a specialization of inanimate > objects (things), which are a specialization of > general things (entities), which are a > specialization of the parent class (which is used > to avoid the withing problem). So, portal > specific operations can be found in > SAM.Entities.Things.Portals. The three (and > counting) specializations of Portals are only > referenced once to initialize them and let them > register themselves into the system. I could use > renames to flatten out the majority of references > (package SAM.Portals renames > SAM.Entities.Things.Portals;), but you can't > inherit from a rename, so the actual children are > still deeply nested. The long package names > usually mean long file names. This could become a > portability problem. > > I'm interested in how other people have dealt with > this problem, or suggestions for how i might deal > with it. 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. This doesn't help with long filenames, but you can use gnatkr to aid cutting down the length of names. Marc A. Criley Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-03 12:56 ` Marc A. Criley @ 2002-12-04 6:56 ` Anders Wirzenius 2002-12-04 12:41 ` Marc A. Criley 0 siblings, 1 reply; 9+ messages in thread From: Anders Wirzenius @ 2002-12-04 6:56 UTC (permalink / raw) "Marc A. Criley" <mcq95@earthlink.net> wrote in message news:3DECAA3A.F3E7BA90@earthlink.net... > 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. > > This doesn't help with long filenames, but you can use gnatkr to aid > cutting down the length of names. > > Marc A. Criley > Quadrus Corporation > www.quadruscorp.com "All but the ""bottom"" package" is an excellent technique! Why have I not discovered that myself ;-( 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. like: with SAM.Entities.Things; ... begin ... code not using SAM.Entities.Things ... define use SAM.Entities.Things; begin Portals.Teleport... end; ... code ... end; Thanks for "allowing" to use your code, Marc. Anders ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-04 6:56 ` Anders Wirzenius @ 2002-12-04 12:41 ` Marc A. Criley 2002-12-06 11:00 ` David Kristola 0 siblings, 1 reply; 9+ messages in thread From: Marc A. Criley @ 2002-12-04 12:41 UTC (permalink / raw) Anders Wirzenius wrote: > > "Marc A. Criley" <mcq95@earthlink.net> wrote in message > news:3DECAA3A.F3E7BA90@earthlink.net... > > 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. > > > > This doesn't help with long filenames, but you can use gnatkr to aid > > cutting down the length of names. > > > > Marc A. Criley > > Quadrus Corporation > > www.quadruscorp.com > > "All but the ""bottom"" package" is an excellent technique! Why have I not > discovered that myself ;-( > > 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. > like: > with SAM.Entities.Things; > ... > begin > ... > code not using SAM.Entities.Things > ... > define > use SAM.Entities.Things; > begin > Portals.Teleport... > end; > ... > code > ... > end; > > Thanks for "allowing" to use your code, Marc. Glad to be of help, and though I didn't mention it, I too also tend to localize most use clauses inside the procedures where they're needed, rather than placing them in the context clause list. Marc ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-04 12:41 ` Marc A. Criley @ 2002-12-06 11:00 ` David Kristola 2002-12-09 15:05 ` Ted Dennison 0 siblings, 1 reply; 9+ messages in thread From: David Kristola @ 2002-12-06 11:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-06 11:00 ` David Kristola @ 2002-12-09 15:05 ` Ted Dennison 0 siblings, 0 replies; 9+ messages in thread From: Ted Dennison @ 2002-12-09 15:05 UTC (permalink / raw) David95038@aol.com (David Kristola) wrote in message news:<5463bc76.0212060300.2f78f4dc@posting.google.com>... > > From: Dale Stanbrough > > 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. No rush. I have written quite a few Free Software projects in Ada, and haven't used "use package" once. Like Ada itself, many of the development standards from the defense industry are good ones. I know this is a contraversial subject, and I don't want to get into a argument with those who think there's nothing wrong with "use package". I'd just like to point out that there's no reason to loosen a development standard you find sensible just because your client is different. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-03 11:44 Style question: deep inheritance David Kristola 2002-12-03 12:55 ` Dale Stanbrough 2002-12-03 12:56 ` Marc A. Criley @ 2002-12-03 14:21 ` Stephen Leake 2002-12-04 19:19 ` Ted Dennison 3 siblings, 0 replies; 9+ messages in thread From: Stephen Leake @ 2002-12-03 14:21 UTC (permalink / raw) David95038@aol.com (David Kristola) writes: > <snip> So, portal > specific operations can be found in > SAM.Entities.Things.Portals. The three (and > counting) specializations of Portals are only > referenced once to initialize them and let them > register themselves into the system. I could use > renames to flatten out the majority of references > (package SAM.Portals renames > SAM.Entities.Things.Portals;), but you can't > inherit from a rename, so the actual children are > still deeply nested. The long package names > usually mean long file names. This could become a > portability problem. Any compiler implementation that limits file names must still allow long package names, and therefore provide a mechanism to map between them. Therefore I don't see how this could become a portability problem, any more than any file naming convention is a portability problem. 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 :). 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? -- -- Stephe ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Style question: deep inheritance 2002-12-03 11:44 Style question: deep inheritance David Kristola ` (2 preceding siblings ...) 2002-12-03 14:21 ` Stephen Leake @ 2002-12-04 19:19 ` Ted Dennison 3 siblings, 0 replies; 9+ messages in thread From: Ted Dennison @ 2002-12-04 19:19 UTC (permalink / raw) David95038@aol.com (David Kristola) wrote in message news:<5463bc76.0212030344.712c30aa@posting.google.com>... > facing some ridiculously long names. For ... > to avoid the withing problem). So, portal > specific operations can be found in > SAM.Entities.Things.Portals. The three (and > counting) specializations of Portals are only > referenced once to initialize them and let them > register themselves into the system. I could use > renames to flatten out the majority of references > (package SAM.Portals renames > SAM.Entities.Things.Portals;), but you can't > inherit from a rename, so the actual children are 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. The only time you'd ever have to use the full name is outside of the SAM hierarchy. In that case, you should *want* to use the full name, to diferentiate SAM.Entities.Things from any other "Things". If the names are annoying because they contain unneeded information, then you shouldn't name things that way. For instance, if it makes no sense to have any other kinds of "Things" inside of SAM, then "Things" should be a sibling package of "Entities" rather than a child. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-12-09 15:05 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-03 11:44 Style question: deep inheritance David Kristola 2002-12-03 12:55 ` Dale Stanbrough 2002-12-03 12:56 ` Marc A. Criley 2002-12-04 6:56 ` Anders Wirzenius 2002-12-04 12:41 ` Marc A. Criley 2002-12-06 11:00 ` David Kristola 2002-12-09 15:05 ` Ted Dennison 2002-12-03 14:21 ` Stephen Leake 2002-12-04 19:19 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox