comp.lang.ada
 help / color / mirror / Atom feed
* 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