[GOODIE] Finding the Interface of a Class (was: Re: Matrix class?)

Andrew P. Black black at cse.ogi.edu
Thu May 3 07:26:00 UTC 2001


At 16:03 +1200 2001.05.03, Richard A. O'Keefe wrote:
>There's not actually a lot in that class.  It might be fun for you to
>list the full protocol of the class, strip out the methods inherited from
>Object, and figure out which other ancestral methods actually work, then
>submit a new version that _doesn't_ inherit from Collection.

Every so often, it is nice to be able to do this -- list the full 
protocol of the class.  I wrote the attached change set to do exactly 
this task.

It defines a class "Interface" that is essentially a set of methods.

The way that this differs from just listing the protocol in the 
browser is that it attempts to recognize methods that are deleted in 
subclasses by redefining them as self shouldNotImplemet, self error: 
'mumble', and so on.   It is based on some code that Will Cook wrote 
for his OOPSLA paper on Conformity and Inheritance in the Smalltalk 
Collection classes, but I reworked it for Squeak.

As a result, extracting the interface of a class can be rather slow. 
But, it beats looking for those error methods by hand.

Currently, these methods no not detect as missing a method that sends 
a missing method.  For example,

	Collection interface includes: #add: ==> false,

because #add: is defined as self subclassResponsibility.  BUT

	Collection interface includes: #addAll: answers true,

even though addAll: is defined as

addAll: aCollection

	aCollection do: [:each | self add: each].
	^ aCollection

If someone can think of a simple way of checking for this case, 
please be my guest!

	Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Interfaces.4.cs
Type: application/octet-stream
Size: 7539 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010503/42e35e8d/Interfaces.4.obj


More information about the Squeak-dev mailing list