[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
|