Multi-Method Statistics 
Author Message
 Multi-Method Statistics

Thanks for the interesting message Steve.

Its worth remembering that the author of HiPWorks came from a mono-method
programming background, and was under severe time constraints - given more
time and experience, the percentage usages of various kinds of methods
would certainly have been different.

When you use a multi-method system you soon come to expect that you can
switch on the classes of multiple arguments as a matter of course.

Its a bit like when you start using a multiple inheritance system after
using a mono inheritance system - you soon start expecting to be able
to inherit from more than one class.

(Of course, going the other direction is harder).

Even if you never actually use multiple inheritance (or multi-methods)
the fact that it is there simplifies the conceptual space, or at least it
does for me. In real life things are rarely black or white and programming
languages should reflect this: why should classes only inherit from one thing?
and why should a method only specify the type of one argument? These seem
to be artificial implementation constraints to me.

This is a fairly weak argument for multi-methods. Steve's argument
is better - to paraphrase: There are some problems which are hard to solve
using mono-method systems, but which have clean, compact and elegant solutions
in multi-method systems.

Having said this, I must admit that I have been very cautious when choosing to
create a multi-method rather than a mono-method. Its like using a power drill
to make a hole in cardboard when you could have used a sharp pencil :-)


Fri, 12 Apr 1996 18:31:31 GMT  
 Multi-Method Statistics
Data for the Mono vs Multi Method Debate
There's been a lot of debate on the (expected) frequency of use of
``real'' multi-methods in CLOS-like systems.  I thought it would be
interesting to measure the statistics for multi vs. mono methods in
HiPWorks.  HiPWorks is a small-medium sized package of 22K lines of code
(including comments and whitespace).  It is, however, fairly complex
and makes what might be called "typical" use of ObjectClass.  ObjectClass
is the CLOS-like extension to Pop11 that I have developed (with much help)
over the past few years.

These statistics are only done on the call-side of the generics.  i.e.  
I have neglected the updater of generics totally.  This gives rise to
a few anomalies.  I'll be addressing this shortcoming in my talk at Expert
Systems 93 (book your tickets, now, folks!)

First a rather dense verbal summary.  This explains some of the
terms used in the more readable table at the end.  You should probably
read this bit in combination with the table.  

Verbal Summary
There are 192 generic procedures in HiPWorks.  Of this, 21 are methods of
0 typed arguments, called "catchall generics".  This means they could just
as easily be written as ordinary procedures.  (Of course, their updaters
might be complex).  156 are simple mono-method generics.  This means that
they could be written in traditional OOL such as Smalltalk.  A further 8
were mono-methods with a catchall method.  In a Smalltalk like system,
these methods require the notion of a top-most class from which all other
inherit.  (This is true in most OOLs.)  The remaining 7 could be divided
into two groups.  5 were simple mono-methods but dispatched on the
second argument rather than the first or principal argument.  These would
require a trivial reordering of arguments to be written in a Smalltalk like
system.  The final group of 2 generics were true multi-methods.  
More on these final two later.

Table of Results
Total number of generics                 192     100%
Pure catchall generics                    21      11%
Pure mono-methods (no catchall)          156      81%
Mono-methods with catchall                 8       4%
Mono-methods in secondary position         5       3%

True multi-method generic                  2       1%

The two "true" multi-method generics were quite different.  One of them had
a single method and the other had nine.  Thus in a mono-method like system,
the first could have been coped with by a single conditional.  The
other would have been more awkward.

I offer no particular comment on these figures as the interpretation
is, in my view, rather complex and all I wanted to do was add some
more data to the debate.  However, I feel obliged to point out that there
is a distinct difference between the mono-methods of a SINGLE inheritance
system (e.g. Smalltalk) and that of a MULTIPLE inheritance system
(e.g. CLOS).  So it is not precisely accurate to suggest that these
mono-methods can be trivially coded in Smalltalk-like systems -- as I
have done above.  My belief is that this is not an important factor,
so I allowed myself the licence to gloss over the details, but this
is an eminently debateable point.


Fri, 12 Apr 1996 01:27:18 GMT  
 [ 2 post ] 

 Relevant Pages 

1. Multi-methods, multi-polymorphism in python

2. Multi-methods in Eiffel

3. multi-method dispatch

4. Are all functions multi-methods?

5. Distributed objects vs. generic functions and multi-methods

6. multi-methods in TR CD ?

7. sequences & multi-methods

8. Message passing versus multi-method

9. multi-methods

10. multi-methods

11. Algebraic simplifier example (was multi-methods)

12. not grasping the method overloading/multi-dispatch thing


Powered by phpBB® Forum Software