Protocol <classDescription> Anomaly

I think protocol <classDescription> should be added to Object.  From
the Draft ANSI Standard:

5.3.8 Protocol: <classDescription>
Conforms To
        <Object>
Description
        This protocol describes the behavior of class objects. It
provides messages for identifying and locating class objects within
the class hierarchy.


When it discusses a "class object" I think it means "as opposed to an
instance object" not "metaclass".  That would, as far as I can tell,
be the class "Object".  I'm not 100% sure, but messages such as
"allSubclasses" seem to indicate this.


5.3.8.1 Message: allSubclasses
Synopsis
        Return all subclasses of a class.
Definition: <classDescription>
        If the receiver is a class object, return a collection containing
all of the class objects whose class definitions inherit either
directly or indirectly from the class definition of the receiver.
        If the receiver is not a class object, the result is unspecified.
-> Each element of the result collection supports the protocol
-> <classDescription>.
        The order of class objects within the collection is unspecified.


Boolean conformsToProtocol: 'classDescription' "-> false"

Boolean class allSuperclasses
allSatisfy: [:el| el conformsToProtocol: 'classDescription']
        "-> false"

Boolean class allSuperclasses
collect: [:el| el conformsToProtocol: 'classDescription']
        "-> an OrderedCollection(true true true true false)"


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

Richard

"Richard A. Harmon" <[hidden email]> wrote in message
news:[hidden email]...
> I think protocol <classDescription> should be added to Object.
>...
> Boolean conformsToProtocol: 'classDescription' "-> false"
>...

The confusion here is over the meaning of #conformsToProtocol: message in
Dolphin. It isn't testing that the receiver conforms to a protocol, but is
implemented in ClassDescription and means "do your instances conform to this
protocol".

If you think of the #canUnderstand: and #respondsTo: messages, then
#conformsToProtocol: message in Dolphin is analagous to the #canUnderstand:
message implemented in Behaviour rather than the than #respondsTo: method of
Object.

With the benefit of hindsight, this was a poor choice. Both types of message
are probably needed - I chose to have only the class side test because the
instance side test is only a convenience, and I abhor the thoughtless
addition of methods to Object. Unfortunately I chose to call the class side
test the name that intuitively belongs to the instance side test, and as a
result it is not intuitive and has confused me on occassion too. I must
confess, however, that I am frequently unsure as to which of #respondsTo:
and #canUnderstand: I need to use. Perhaps though this is because their use
is an indication of poor design, and so is something one does (or hopes to
do) very infrequently.

To continue in the same confusing tradition as those single message testing
methods, we probably need to add a #respondsToProtocol: method on the
instance side of Object. Alternatively we need to burn the disk packs, grab
#conformsToProtocol: to mean "Do you, yes you, conform to this protocol",
and come up with a suitable selector for "Do your instances conform to this
protocol" for the class side.

As none of this is standardized, I think it might be worthwhile putting
forward a proposal before it is too late. Perhaps under the auspices of Camp
Smalltalk?

> Boolean class allSuperclasses
> collect: [:el| el conformsToProtocol: 'classDescription']
> "-> an OrderedCollection(true true true true false)"

What you're seeing there of course is the circularity through Object class
which ends up in the Behavior hierarchy and eventually at Object.

BTW: We normally use symbolic names for protocols, and it is more efficient
to do so.

Regards

Blair

On Fri, 17 Nov 2000 19:37:21 -0000, "Blair McGlashan"
<[hidden email]> wrote:
[snip]

Sorry, I managed yet again to get myself totally confused about Class,
Metaclass, and inherited behavior.  Thanks for the help.


I think you did a terrific job on protocols.  They are one more plus
for Dolphin.


[snip]
>To continue in the same confusing tradition as those single message testing
>methods, we probably need to add a #respondsToProtocol: method on the
>instance side of Object. Alternatively we need to burn the disk packs, grab
>#conformsToProtocol: to mean "Do you, yes you, conform to this protocol",
>and come up with a suitable selector for "Do your instances conform to this
>protocol" for the class side.

Or alternatively to keep the confusion reliably consistent, add
Behavior>>#canUnderstandProtocol:?


>As none of this is standardized, I think it might be worthwhile putting
>forward a proposal before it is too late.

Excellent suggestion.  I'll work something up to post on c.l.s.


> Perhaps under the auspices of Camp Smalltalk?

I am in the process of cleaning up my Camp Smalltalk SUnit additions
using protocols.

Thanks for your previous suggestions.  I've incorporated a number of
them and they were extremely helpful.  Maintaining a parallel
dictionary that maps each class to the protocols it supports
simplified things a bunch.


>> Boolean class allSuperclasses
>> collect: [:el| el conformsToProtocol: 'classDescription']
>> "-> an OrderedCollection(true true true true false)"
>
>What you're seeing there of course is the circularity through Object class
>which ends up in the Behavior hierarchy and eventually at Object.

Yup.  You right.  I think I bumped into myself in that circularity.


>BTW: We normally use symbolic names for protocols, and it is more efficient
>to do so.

In my protocol stuff I found I was using #asSymbol all over the place
so I changed my stuff's methods that needed a protocol to take a
<readableString> and just used asSymbol when need internally.  I'll
see if I shot myself in the foot by doing this.


Sorry for the false alarm.


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy