Design Principles Behind Smalltalk | Hacker News Reader

Design Principles Behind Smalltalk

cs.virginia.edu

27 pointsandreyf4 comments

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.

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).

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.

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.

Reply on news.ycombinator.com