From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Subject: Re: Procedure types and dynamic binding
Date: 9 Jan 89 01:47:50 GMT [thread overview]
Message-ID: <4046@hubcap.UUCP> (raw)
In-Reply-To: 5796@medusa.cs.purdue.edu
From article <5796@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
>> [Discussion of unrestricted pointers]
>
> Do you mean passing unrestricted pointers to procedures and then
> selecting the procedure via overloading (ad-hoc polymorphism) at runtime?
> I meant allowing polymorphic parameters to a particular subprogram,
> such as
> procedure test (parameter : polymorphic; ...) is ...
Yes, that's what I had in mind, although I would also provide
procedure INSERT_ITEM (TARGETED_STACK : in out STACK;
NEW_ITEM : in OBJECT);
to avoid making the user set up a pointer just to get a parameter passed.
The resulting situation would be the same as if an unrestricted pointer
had been used and POINTER.all had been made to serve the same function.
> [An extended example of toggling between two print procedures]
>
> procedure MAKE_SHORT_PRINT (); -- sets PRINT up to call SHORT_PRINT,
> -- a user-supplied generic parameter
>
> procedure MAKE_LONG_PRINT (); -- sets PRINT up to call LONG_PRINT,
> -- a user-supplied generic parameter
>
> procedure PRINT (); -- a service provided to the user
> Now, a call to print an instance of this class will at first result in
> invocation of the SHORT_PRINT parameter. But programmers can make
> subsequent calls to PRINT for this instance use long_print
> through a call to MAKE_LONG_PRINT. Each instance can parameterize
> its print subprogram to output its data as desired. Other tricks
> could be used but this method avoids the use of case statements and
> is a simple use of procedural variables.
> In more complicated examples parameterizable operations for each Adt
> instance could simplify the program considerably, such as by avoiding
> nested case statements.
But you've designed your ADT to handle only two types of printing
situations: SHORT_PRINT and LONG_PRINT (or at least this would seem
to be the case to anyone who takes your generic parameter structure
at face value). What we REALLY want is for ANY type of printing
operation to occur, depending on the user's needs, which we cannot
forecast in advance. But now look at the trap we've walked into:
we must provide MAKE_*_PRINT, where * represents an indefinite set
of cases. We now see that our old friend, the case statement, is
not gone; it has simply taken on a new form.
Verdict: a bad ADT design idea.
Now let us step back for a moment and consider our situation. We
wish to accept a PRINT procedure from our user, which we will use
in the course of printing out the contents of the stack. But how
do we know that the method we choose for encapsulating the stacked
objects in the printout will make our user happy? Perhaps our idea
is to print each object, separated by a blank line, but our user
wants to see each object surrounded by a rectangular box of :-)s...
We now see that our entire approach to the problem is wrong. We must
provide a method whereby our user can access his/her stacked objects,
and allow the user to implement any arbitrary print procedure. But,
you object, the user must be given some sort of standard print procedure
which can be used as a default! And so he/she must; we achieve this
by supplying in a utilities package the following:
with TEXT_IO;
generic
type DATA_STRUCTURE is limited private;
type STORED_OBJECT is limited private;
with procedure NEXT_POSITION (STRUCTURE : in out DATA_STRUCTURE);
with function GET_CURRENT_ITEM
(STRUCTURE : in DATA_STRUCTURE)
return STORED_OBJECT;
with procedure PRINT (TO_FILE : in TEXT_IO.FILE_TYPE;
THE_ITEM : in STORED_OBJECT );
procedure STANDARD_PRINT_ROUTINE (INTO_FILE : in TEXT_IO.FILE_TYPE;
STRUCTURE : in DATA_STRUCTURE);
Our user is now provided with maximal power and convenience.
Note that the above utility applies to any class of structures
for which the user can construct a procedure to sequentially
access every stored object in some user-defined order.
Still waiting for a situation in which procedural variables should
be used in order to formulate an intuitively natural solution...
Bill Wolfe
wtwolfe@hubcap.clemson.edu
next prev parent reply other threads:[~1989-01-09 1:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
1988-12-30 21:42 Procedure types and dynamic binding Erland Sommarskog
1988-12-31 17:46 ` Bob Hathaway
1989-01-05 10:02 ` William Thomas Wolfe,2847,
1989-01-07 18:05 ` Bob Hathaway
1989-01-07 21:21 ` William Thomas Wolfe,2847,
1989-01-08 1:49 ` Bob Hathaway
1989-01-08 19:01 ` William Thomas Wolfe,2847,
1989-01-08 23:10 ` Bob Hathaway
1989-01-09 1:47 ` William Thomas Wolfe,2847, [this message]
1989-01-09 20:19 ` Bob Hathaway
1989-01-10 3:01 ` William Thomas Wolfe,2847,
1989-01-10 3:06 ` Bob Hathaway
1989-01-10 19:11 ` William Thomas Wolfe,2847,
1989-01-11 2:08 ` Bob Hathaway
1989-01-11 14:24 ` William Thomas Wolfe,2847,
1989-01-11 17:51 ` Barry Margolin
1989-01-11 22:54 ` William Thomas Wolfe,2847,
1989-01-12 13:57 ` Robert Firth
1989-01-12 19:09 ` William Thomas Wolfe,2847,
1989-01-14 0:46 ` Scott Moody
1989-01-15 18:28 ` William Thomas Wolfe,2847,
1989-01-24 4:07 ` Paul Stachour
1989-01-12 0:58 ` William Thomas Wolfe,2847,
1989-01-12 6:12 ` Barry Margolin
1989-01-11 14:48 ` Submitting Ada 9X revision requests William Thomas Wolfe,2847,
1989-01-11 2:10 ` Procedure types and dynamic binding Bob Hathaway
1989-01-05 7:38 ` William Thomas Wolfe,2847,
-- strict thread matches above, loose matches on Subject: below --
1989-01-06 23:04 Erland Sommarskog
1989-01-07 22:20 ` William Thomas Wolfe,2847,
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox