

Design Principles Behind Smalltalk - andreyf
http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html?

======
chriseidhof
Very cool. One quote hit me : " A conventional statement of this principle is
that a program should never declare that a given object is a SmallInteger or a
LargeInteger, but only that it responds to integer protocol. Such generic
description is crucial to models of the real world."

I've been thinking about an OO language where there is no subclassing.
However, you do have protocols (interfaces) and super-protocols. This might
even allow for full type inference.

~~~
albertzeyer
I think for example ObjC is like this (or at least it is heavily done like
that with protocols). Except for the primitive C types like int (i.e. not
everything is an object in ObjC).

~~~
chriseidhof
I only know Cocoa Touch, but there it's not really the case. Parts of it are
done using protocols, but a lot is still classical inheritance.

~~~
alextgordon
It's not just explicit @protocols. _Everything_ in Objective-C is under an
implicit protocol: the code itself. Even if a method says it requires an
argument of type Foo, you can usually substitute an object of type Bar, so
long as Bar responds to all the messages that the method could send to Foo.

For example

    
    
        - (void)printValue:(Foo *)foo {
            NSLog(@"%@", [foo stringValue]);
        }
    

it doesn't matter that printValue: _says_ it wants a Foo, you can still pass
it an NSTextField all the same.

This gets really fun when you start using -respondToSelector: Now we can do:

    
    
        - (void)printValue:(Foo *)foo {
            if ([foo respondsToSelector:@selector(stringValue)])
               NSLog(@"%@", [foo stringValue]);
        }
    

This sort of thing is used throughout Cocoa (although these days explicit
protocols are replacing it). It's difficult to do in C++, which is one of the
reasons why C++ UI toolkits are so cumbersome.

