Need advice: Enumerate or not

Need advice: Enumerate or not

[Preben Randhol]

Hi

I'm developing a GtkAda application. I have a window and in this window
I need to put an object depending on when the user wants. That is if he
wants to add words then I remove the object that is there and add the
object that deals with adding words, if he wants to be questioned then I
have to put another object etc...

What I'm wondering is that I now see that I need to call an update
procedure for the object that is currently in the window if the user has
done some changes in the preferences. The objects are all derived from
an object in Gtkada called Gtk_Frame, but they are in different packages
and the update procedure will also be in these seperate packages. So I
was thinking either I can do some dispatching thing or I can use
Enumerates like this: 

   with Listing;
   with Examine;
   with Setup;

   procedure Update (Which_Object : Object_Enum_Type) is
   begin
      case Which_Object is
         when Add =>
            Listing.Update;
         when Examine => 
            Examine.Update;
         when Setup => 
            Setup.Update;
         when others =>
            null;
      end case;
   end Update;

or

   with Listing;    use Listing;
   with Examine;    use Examine;
   with Setup;      use Setup;

   --  I would have to use use here which I don't like

   procedure Update (Object : access Gtk_Frame_Record) is
   --                         ^^^^^^^^^^^^^^^^^^^^^^^
   --                         Perhaps I need to write sth else here, I'm
   --                         not sure as I haven't tested it yet.
   begin
      Update (Object);
   end Change_Mode;

Which would be the more sensible way to go?

Thanks for any hints in advance.

Preben

Re: Need advice: Enumerate or not

[Jim Rogers]

Both approaches will work.

The use of enumerated types is clearly more of an Ada 83 design
pattern. Its limitation is that you must update the source code
for the Update procedure when new options are permitted.

The use of dispatching is clearly more of an Ada 95 design
pattern. Its main advantage is that you never need to change
the Update procedure taking a parameter of type
"access Gtk_Frame_Record'Class". All you need to do is override the
Update procedure for the new child type of Gtk_Frame_Record.

The Ada 95 approach is perhaps harder to read, because all the
decisions are performed by dispatching and not by explicit
branching in your code. On the other hand, the dispatching
approach reduces maintenance cost and explicit complexity.

Jim Rogers

Re: Need advice: Enumerate or not

[Preben Randhol]

On Wed, 15 May 2002 12:26:50 GMT, Jim Rogers wrote:
> The Ada 95 approach is perhaps harder to read, because all the
> decisions are performed by dispatching and not by explicit
> branching in your code. On the other hand, the dispatching
> approach reduces maintenance cost and explicit complexity.

The only thing I must do is:

with Some_New_pacakge; use Some_New_pacakge; 

and make sure that the pacakges supply an update fuction.

Thanks.

Preben

Re: Need advice: Enumerate or not

[Stephen Leake]

Preben Randhol <randhol+abuse@pvv.org> writes:

> On Wed, 15 May 2002 12:26:50 GMT, Jim Rogers wrote:
> > The Ada 95 approach is perhaps harder to read, because all the
> > decisions are performed by dispatching and not by explicit
> > branching in your code. On the other hand, the dispatching
> > approach reduces maintenance cost and explicit complexity.
> 
> The only thing I must do is:
> 
> with Some_New_pacakge; use Some_New_pacakge; 

No, the child package where the actual operation is defined does _not_
need to be visible for dispatching to happen. That is crucial to the
dispatching design; the top level Update procedure can be written with
_no_ knowledge of what procedures are actually dispatched to.

> and make sure that the pacakges supply an update fuction.

This is done by making the root operation abstract; then the compiler
ensures that each derived type supplies an update function.


I suggest you write a very simple application that does dispatching,
so you get a better feel for how it works. Model the hierarchy you are
thinking of here, but just do Text_IO, so it's easy to get it working.
Then you can decide how to proceed with the real application.

-- 
-- Stephe

Re: Need advice: Enumerate or not

[Preben Randhol]

On 16 May 2002 09:03:25 -0400, Stephen Leake wrote:

> No, the child package where the actual operation is defined does _not_
> need to be visible for dispatching to happen. That is crucial to the
> dispatching design; the top level Update procedure can be written with
> _no_ knowledge of what procedures are actually dispatched to.

But as I said these objects are in different packages which are not 
child packages of a package. Doe they need to be?

> This is done by making the root operation abstract; then the compiler
> ensures that each derived type supplies an update function.

Yes I have done this in my Common_Dialog package as there I have a
"root" package which has an abstract type that the child packages
derive. In my other case I don't have that.

-- 
Preben

Re: Need advice: Enumerate or not

[Jeffrey Carter]

Jim Rogers wrote:
> 
> The use of enumerated types is clearly more of an Ada 83 design
> pattern. Its limitation is that you must update the source code
> for the Update procedure when new options are permitted.
> 
> The use of dispatching is clearly more of an Ada 95 design
> pattern. Its main advantage is that you never need to change
> the Update procedure taking a parameter of type
> "access Gtk_Frame_Record'Class". All you need to do is override the
> Update procedure for the new child type of Gtk_Frame_Record.
> 
> The Ada 95 approach is perhaps harder to read, because all the
> decisions are performed by dispatching and not by explicit
> branching in your code.

To summarize, enumeration types are easier to read but require writing
more code. Dispatching (OOP) is harder to read but requires less coding.

Ada has as an explicit design goal of emphasizing ease of reading over
ease of writing. Thus Rogers' statements support the claim that
dispatching is not in the spirit of Ada.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: Need advice: Enumerate or not

[Jim Rogers]

Jeffrey Carter wrote:

> To summarize, enumeration types are easier to read but require writing
> more code. Dispatching (OOP) is harder to read but requires less coding.
> 
> Ada has as an explicit design goal of emphasizing ease of reading over
> ease of writing. Thus Rogers' statements support the claim that
> dispatching is not in the spirit of Ada.
> 


That is a little unfair. I did not say that dispatching is contrary
to the spirit of Ada. I did say it was not a typical Ada 83 design
pattern.

One goal of Ada is readability. Another is efficient maintenance.
Those two goals are not always harmonious with each other.
Dispatching can simplify maintenance by limiting the dependencies
between packages compared to those encountered using explicit
enumeration and case statements. This lowers the costs of compilation,
testing and release (all valid parts of software maintenance).

As with other features of Ada, or any other language, you need to
find a balance between extreme positions in your design. Avoiding all
dispatching MAY be correct for one set of requirements, while
inappropriate for another set of requirements. We are fortunate that
Ada allows us to make the appropriate engineering decisions. Some
languages do not allow these engineering decisions.

Jim Rogers

Re: Need advice: Enumerate or not

[Robert Dewar]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CE2A23D.850BA244@acm.org>...

> To summarize, enumeration types are easier to read but require writing
> more code. Dispatching (OOP) is harder to read but requires less coding.

Not by any means universally true, depends upon the situation

> Ada has as an explicit design goal of emphasizing ease of reading over
> ease of writing. Thus Rogers' statements support the claim that
> dispatching is not in the spirit of Ada.

If meant as a general statement, this is a very peculiar claim.

The real rule in Ada is use the appropriate design to make the code as easy
as possible to read *and* maintain. Sometimes dynamic dispatching meets this
criterion, sometimes it fails. 

Those who insist on using dispatching and extended types for everything doom
themselves to write rubbish code that is hard to read and hard to maintain in
some situations.

Those who absolutely refuse to use dispatching and type extension ever doom
themselves to the same fate.

Why is it in the PL area that people get so absolute. Very odd!

Re: Need advice: Enumerate or not

[Preben Randhol]

On 15 May 2002 19:37:05 -0700, Robert Dewar wrote:
> 
> The real rule in Ada is use the appropriate design to make the code as easy
> as possible to read *and* maintain. Sometimes dynamic dispatching meets this
> criterion, sometimes it fails. 
> 
> Those who insist on using dispatching and extended types for everything doom
> themselves to write rubbish code that is hard to read and hard to maintain in
> some situations.
> 
> Those who absolutely refuse to use dispatching and type extension ever doom
> themselves to the same fate.

OK I see. I see now that it makes sense to use dispatching in one place
and enumerated types in another in the program I'm making.

Thanks!

Preben
-- 
                 �For me, Ada95 puts back the joy in programming.�

Re: Need advice: Enumerate or not

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3CE2A23D.850BA244@acm.org>...
> 
> > To summarize, enumeration types are easier to read but require writing
> > more code. Dispatching (OOP) is harder to read but requires less coding.
> 
> Not by any means universally true, depends upon the situation
> 
> > Ada has as an explicit design goal of emphasizing ease of reading over
> > ease of writing. Thus Rogers' statements support the claim that
> > dispatching is not in the spirit of Ada.
> 
> If meant as a general statement, this is a very peculiar claim.
> 
> The real rule in Ada is use the appropriate design to make the code as easy
> as possible to read *and* maintain. Sometimes dynamic dispatching meets this
> criterion, sometimes it fails.

I'm always glad to stir up some controversy, even if I have to stretch
things to get there.

My statements quoted above were in the context of Rogers' original
statements. However, it has been my experience and that of many others
that there is a positive correlation between ease of reading and ease of
modification. This is because the modifier must first understand the
code before he may modify it.

When the use of dispatching makes the code harder to read, as in the
case in question, it is generally true that it also makes the code
harder to modify.

-- 
Jeff Carter
"If you think you got a nasty taunting this time,
you ain't heard nothing yet!"
Monty Python and the Holy Grail