Smalltalk and IoC

Question

I see a lot of IoC frameworks for .Net and Java. Does anyone know why there are no equivalent frameworks for Smalltalk. This is more a philosophy question than anything else. I'm wondering if there is something in the Smalltalk way of doing things that precludes the necessity of having an IoC framework.

Answer 1

MVC was invented on Smalltalk and is arguably the original Inversion of Control framework. While somewhat more lightweight than its java counterparts, it has the basic concepts of a model holding the data, a view rendering the data in response to events propogated from a controller.

Less flippantly, Java is actually needs a lot of framework support to do a web application without excessive quantities of boilerplate code. Smalltalk supports programming idioms such as continuations, which allow an author to pretend they are not really writing event driven code. Seaside works like this, giving the benefits of IoC with a somewhat more flexible development paradigm.

EDIT: MVC is a framework for UI's in Smalltalk (arguably it's not really a framework as such, but the class library has built in support for it). It has the inversion of control property in that the view and model respond to events dispatched by the controller - the don't call us, we'll call you property. Inversion of Control is a design pattern within frameworks that's used to reduce the need for extensive boilerplate in java applications. In some definitions of an application framework, Inversion of Control is the main property that is viewed as distinguishing a framework from a library.

Answer 2

Functions are first class citizens in smalltalk, so it is easy to have IoC without a framework.

Answer 3

I think that IOC or the Dependency Injection pattern solves a problem that doesn't really exist in the Smalltalk environment. Smalltalk is an untyped dynamic language and uses message passing to communicate. This makes for objects that are loosely coupled by nature at the language level. Any object can send a message to another object without regard to the type as long as it can process the message. So, as you might guess changing dependencies at any given time is relatively easy and natural. Just have to decide where, when, and how you want to change the dependency.

Answer 4

A few possible reasons for this. One is that we haven't bothered to use the "IoC" qualifier, which is essentially redundant - since calling something a framework implies the inversion of control flow.

Another is that the Smalltalk language provides direct support for "IoC" flows - in the form of closures. One result of programming with closures is that the flow of control as found in frameworks doesn't seem so starkly different as to evoke a sense of being "inverted" from a "normal" sense of flow; rather, with closures, the flow of control is flipping back and forth between these two perspectives all of the time, and everywhere. Even within single statements.

A third reason, perhaps, is that, even without closures, the "inversion of control" being described is not uniquely associated with frameworks - the same flows are found in most forms of code that involve I/O.

Fourth, Smalltalkers probably use these sorts of flows even more than others, as we lean more heavily on the notions of objects and the messages sent between them than on the notions of structures and the calling of member functions. In the absense of closures, these two views are equivalent, and interchangeable, but the addition of closures changes the result - the sense of control flow in use is one of the effects.

Finally, one might even think about describing the REPL style of control flow as a "simpler", but "inverted" sense of the "normal" flow, normal in the sense that it is used nearly everywhere else.

In summary, the same sorts of frameworks exist for Smalltalk. We describe them a bit differently is all. The difference is, at least in part, due to the presence and utilization of closures in Smalltalk, which many other environments do not yet provide -- -- notably C++, C#, and Java.