* Package hierarchy. Extensibility.
@ 2009-03-12 0:02 Jarno Neniu
2009-03-12 7:26 ` Niklas Holsti
0 siblings, 1 reply; 5+ messages in thread
From: Jarno Neniu @ 2009-03-12 0:02 UTC (permalink / raw)
Hello. I'm not able to decide about which design is the best
(extensibility, maintainability and recompilation friendliness are
important), so I'm demanding for any humble and not so humble
opinions. As an example of hierarchy consider representation of
geometrical points. One of representations is preferable and
considered to be the main representation (Cartesian 2D and 3D points),
but there is unspecified amount of other representations, which could
be added to the system later (points in polar, spherical, cylindrical
coordinate systems). Conversion between representations should be
somehow available and it is desirable for representations to be
generic. Which is the best way to design the hierarchy? Should it be
something like this:
package Points is
-- Preferable representation. Cartesian point.
type Point is ...
end Points;
package Points.Spherical is
type Spherical_Point is ...
end Points.Spherical;
package Points.Cylindrical is
type Cylindrical_Point is ...
end Points.Cylindrical;
Or should it be dummy package «Points» to which other representations
are connected:
package Points is
end Points;
package Points.Cartesian is
type Cartesian_Point is ...
end Points.Cartesian;
package Points.Spherical is
type Spherical_Point is ...
end Points.Spherical;
Something else?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Package hierarchy. Extensibility.
2009-03-12 0:02 Package hierarchy. Extensibility Jarno Neniu
@ 2009-03-12 7:26 ` Niklas Holsti
2009-03-13 1:31 ` Jarno
0 siblings, 1 reply; 5+ messages in thread
From: Niklas Holsti @ 2009-03-12 7:26 UTC (permalink / raw)
Jarno Neniu wrote:
> Hello. I'm not able to decide about which design is the best
> (extensibility, maintainability and recompilation friendliness are
> important), so I'm demanding for any humble and not so humble
> opinions. As an example of hierarchy consider representation of
> geometrical points. One of representations is preferable and
> considered to be the main representation (Cartesian 2D and 3D points),
> but there is unspecified amount of other representations, which could
> be added to the system later (points in polar, spherical, cylindrical
> coordinate systems). Conversion between representations should be
> somehow available and it is desirable for representations to be
> generic. Which is the best way to design the hierarchy? Should it be
> something like this:
>
> package Points is
> -- Preferable representation. Cartesian point.
> type Point is ...
> end Points;
>
> package Points.Spherical is
> type Spherical_Point is ...
> end Points.Spherical;
>
> package Points.Cylindrical is
> type Cylindrical_Point is ...
> end Points.Cylindrical;
>
> Or should it be dummy package �Points� to which other representations
> are connected:
>
> package Points is
> end Points;
>
> package Points.Cartesian is
> type Cartesian_Point is ...
> end Points.Cartesian;
>
> package Points.Spherical is
> type Spherical_Point is ...
> end Points.Spherical;
>
> Something else?
An interface type that defines the common view of "Points" of
whatever representation? That would allow non-hierarchical and
independent implementations of the representations as long as every
representation implements this interface.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Package hierarchy. Extensibility.
2009-03-12 7:26 ` Niklas Holsti
@ 2009-03-13 1:31 ` Jarno
2009-03-13 10:58 ` Niklas Holsti
0 siblings, 1 reply; 5+ messages in thread
From: Jarno @ 2009-03-13 1:31 UTC (permalink / raw)
Niklas Holsti:
> An interface type that defines the common view of "Points" of
> whatever representation? That would allow non-hierarchical and
> independent implementations of the representations as long as every
> representation implements this interface.
Can you please post a simple example? Does interface means extendable
type («interface» or «tagged»)? I think run-time dispatching would be
too much heavy. Seems that I need to organize a bunch of generic
interconvertible types and still be able to add other representations
later with minimal cost.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Package hierarchy. Extensibility.
2009-03-13 1:31 ` Jarno
@ 2009-03-13 10:58 ` Niklas Holsti
2009-03-13 11:03 ` Niklas Holsti
0 siblings, 1 reply; 5+ messages in thread
From: Niklas Holsti @ 2009-03-13 10:58 UTC (permalink / raw)
Jarno wrote:
> Niklas Holsti:
>
>> An interface type that defines the common view of "Points" of
>> whatever representation? That would allow non-hierarchical and
>> independent implementations of the representations as long as
>> every representation implements this interface.
>
> Can you please post a simple example? Does interface means
> extendable type (�interface� or �tagged�)?
Yes, I meant types that extend (implement) an interface type. I had
in fact missed that your original posting did not make these
"Point" types tagged, that is, you did not ask about a *type*
hierarchy but only about a *package* hierarchy.
This being the case, I don't see enough information in your
original posting to answer your question. If these types have
nothing else in common but their use to represent 2D or 3D points,
and the existence of conversions between them, there is little
basis for evaluating your alternatives.
The only reason for using child packages would be to organize your
package names hierarchically, which is of course nice but
introduces unnecessary compilation dependencies, especially if you
declare the "preferable representation" in the common parent
package. So that much can be answered: to minimize compilation
dependencies, parent packages should contain only stuff that is
common (in some sense) to all children.
You also said:
> .. it is desirable for representations to be generic.
By "generic", do you mean that you will have generic units that
take a formal type parameter to specify which "Point"
representation they use? Such as:
generic
type Point_Type is private;
<formal operations on Point_Type>
procedure Rotate_Figure ...
If so, you must ensure that the various kinds of "Point" all
implement compatible operations, to be associated with the <formal
operations> in the generic instances.
If you use a tagged type hierarchy or an interface type, operations
like Rotate_Figure can be class-wide, rather than generic, or can
avoid the declaration of <formal operations> by using instead the
primitive operations of the formal type parameter.
> Seems that I need to organize a bunch of generic
> interconvertible types and still be able to add other
> representations later with minimal cost.
Do you need conversion from any "point" type to any other "point"
type? That would be a quadratic number of conversions, which is to
be avoided, of course. If all "point" types implement a common
interface, you could write a single "constructor" function for each
"point" type, say PT, that creates an object of type PT from any
parameter that implements this interface. This single function can
then be used to convert any other "point" object to an object of
type PT.
There may be a small decrease in floating-point numerical accuracy
in this approach, because it is like first converting the source
type to a "preferable" type (the interface), and then from there to
the target type, with round-offs in both conversions.
> I think run-time dispatching would be too much heavy.
Using tagged types or interfaces has two penalties: extra space in
each object to store the tag, and extra execution time *if*
run-time dispatching is used. But I sense that you want to have
different "point" representations because you want to use the most
suitable representation for each algorithm. If you write your
algorithms as type-specific rather class-wide, the compiler should
bind all operations statically, even if the types are tagged.
The need to assign and copy tags implies a (small) time penalty
even if operations are statically bound. If this is important to
you, or if the space overhead of tags is important, I would
recommend a two-layer approach: define the various "Point" types as
untagged, and then define a "wrapping" tagged type hierarchy (or
interface-implementing types) that has some such untagged "Point"
type as a component. You can then write your type-specific
algorithms using the untagged types, and "wrap" them into objects
of the tagged type(s) when you want to be class-wide. For example:
-- The untagged representations:
type Cartesian_Point is record .. end record;
type Spherical_Point is record .. end record;
-- The tagged representations:
type Tagged_Point is abstract tagged null record;
type Tagged_Cartesian_Point is new Tagged_Point
with record Point : Cartesian_Point; end record;
type Spherical_Cartesian_Point is new Tagged_Point
with record Point : Spherical_Point; end record;
-- The algorithms:
procedure Cartesian_Algo (P : Cartesian_Point) is ...
procedure Spherical_Algo (P : Spherical_Point) is ...
procedure Class_Wide_Algo (P : Tagged_Point'Class) is ...
HTH,
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Package hierarchy. Extensibility.
2009-03-13 10:58 ` Niklas Holsti
@ 2009-03-13 11:03 ` Niklas Holsti
0 siblings, 0 replies; 5+ messages in thread
From: Niklas Holsti @ 2009-03-13 11:03 UTC (permalink / raw)
Whoops:
Niklas Holsti wrote:
> type Spherical_Cartesian_Point is new Tagged_Point
> with record Point : Spherical_Point; end record;
I meant:
> type Tagged_Spherical_Point is new Tagged_Point
> with record Point : Spherical_Point; end record;
Sorry...
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-03-13 11:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-12 0:02 Package hierarchy. Extensibility Jarno Neniu
2009-03-12 7:26 ` Niklas Holsti
2009-03-13 1:31 ` Jarno
2009-03-13 10:58 ` Niklas Holsti
2009-03-13 11:03 ` Niklas Holsti
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox