On 12-10-12 1:37 PM, Colin Putney wrote:
> On Fri, Oct 12, 2012 at 9:21 AM, Chris Cunnington
> <smalltalktelevision at gmail.com> wrote:
>
>> And so I'm guessing that this idea of splitting a protocol from its class
>> has bled into Squeak from Objective-C in the form of Traits. Casimiro must
>> have a reason for using them that he likes. But they do seem like a
>> workaround as a result of a shallow hierarchy. I think I'd rather create my
>> own abstract superclass to define an interface.
> You might find this interesting:
>
> http://www.jot.fm/issues/issue_2002_05/article1/
>
> It's a paper about SmallInterfaces, which created first-class
> interfaces (in Java parlance) for Smalltalk. There was a Squeak port
> that ran in Squeak 3.2 IIRC.
That was interesting. I read it, though, I think I'll have to read it 
again in a few days to get a better idea.
>
> I find it much more fruitful to think about protocols rather than
> classes when designing or analyzing OO systems.
Hmm. That's interesting.

> This fits in nicely
> with what you said about composition being better than inheritance.
> But there are a few issues with a protocol-centric view in Smalltalk:
>
> One is that we don't really need formal protocols the way Java or
> Objective-C do, because of the flexibility of Smalltalk. Objective-C
> uses protocols to allow classes to be extended even when you don't
> have the source code to the object that you're extending.
That's a good point. They are a bit more restricted.
> Java uses
> interfaces to allow polymorphism between classes that aren't related
> by inheritance. In both cases, formalized protocols work around a
> problem caused by the mechanics of the language or it's tools. In
> Smalltalk, doing everything in-image, we don't have those problems.
>
> Given that protocol-oriented programming is so good, it would be nice
> to have better support for that mode of thinking. I bet, for example,
> that there's a latent "Map" protocol in the image, which is a subset
> of the methods that Dictionary implements. It's #at: and #at:put: plus
> a few other supporting methods, but *not* the whole protocol
> implemented by Dictionary and certainly not all the stuff it inherits
> from Collection. I'd love to see a tool that would let us discover
> these latent protocols, name them, and then view and manipulate the
> system based on them.
An automated code archaeologist? The only thing I can think of similar 
to that is studying old images (i.e. 2.7) and comparing them to today. 
What kind of criteria would such a tool use? <Spock>Fascinating.</Spock>

Chris