Style question: deep inheritance

Style question: deep inheritance

[David Kristola]

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

Re: Style question: deep inheritance

[Dale Stanbrough]

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

Re: Style question: deep inheritance

[Marc A. Criley]

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

Re: Style question: deep inheritance

[Stephen Leake]

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

Re: Style question: deep inheritance

[Anders Wirzenius]

"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

Re: Style question: deep inheritance

[Marc A. Criley]

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

Re: Style question: deep inheritance

[Ted Dennison]

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.

Re: Style question: deep inheritance

[David Kristola]

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

Re: Style question: deep inheritance

[Ted Dennison]

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.