* Type conversions forced by derived type: alternative?
@ 1996-09-04 0:00 John Woodruff
1996-09-05 0:00 ` Robert A Duff
0 siblings, 1 reply; 2+ messages in thread
From: John Woodruff @ 1996-09-04 0:00 UTC (permalink / raw)
In a recent discussion about "Two ideas for the next Ada Standard"
Robert offered the advice
> If you are writing a lot of type conversions (I guess that is what you
> mean by using the Algol-68 term cast), then probably you are making
> a common beginner's mistake of using derived types *too* heavily.
> Yes, it is a strong point of Ada that you can use derived types
> to separate different kinds of types, but is a weak point of many
> Ada programs that they overuse this feature and use derived types
> where subtypes would be more appropriate.
Since I have been bothered recently about making a lot of such
conversions, let me ask whether I am overlooking a simple way to avoid
the common (not a beginner, I ;-) mistake.
The type I'm declaring is private and is completed by providing an ADT
instantiation within the private part:
with Tree; -- from Booch components
package Junk is
type Object is private;
procedure Do_Something (O : Object) ;
private
type Node is
record
Label : String (1..5) ; -- for this exercise
end record;
package Implementation is new
Tree (Item => Node,
Expected_Number_Of_Children => 5) ;
type Object is new Implementation.Tree; -- subtype doesn't fit here
end ;
The consequence is that inside the body of this package (and its
children) everyplace I want to operate on the structure of the Object, I
have to convert the parameter of type Object into an Implementation.Tree
-- ad infinitum --.
package body Junk is
procedure Do_Something (O : Object) is
use Implementation ;
begin -- See what I mean?
if Item_Of(Implementation.Tree (O)).Label = "Hello" then
null;
end if ;
end Do_Something;
end ;
I am pretty tired of that! If there is an alternative, please show me.
It's ugly and I'm not very good at writing the conversions, so I make a
certain number of errors. (Is there a way that renaming, or a Use
declaration, or whatever, can let me say Item_Of(O) instead of the
conversion I have here?
--
John Woodruff N I F \ ^ /
Lawrence Livermore National Lab =====---- < 0 >
510 422 4661 / v \
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Type conversions forced by derived type: alternative?
1996-09-04 0:00 Type conversions forced by derived type: alternative? John Woodruff
@ 1996-09-05 0:00 ` Robert A Duff
0 siblings, 0 replies; 2+ messages in thread
From: Robert A Duff @ 1996-09-05 0:00 UTC (permalink / raw)
In article <udk9uadn0n.fsf@tanana.llnl.gov>,
John Woodruff <woodruff1@llnl.gov> wrote:
> type Object is new Implementation.Tree; -- subtype doesn't fit here
Object inherits the primitive ops of Tree, so...
> if Item_Of(Implementation.Tree (O)).Label = "Hello" then
the type conversion should not be necessary. Unless I'm missing
something. I assume Item_Of is a primitive op of type Tree, and should
therefore be inherited by type Object?
- Bob
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1996-09-05 0:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-09-04 0:00 Type conversions forced by derived type: alternative? John Woodruff
1996-09-05 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox