> If one is trying to pass a block-like object to a message that is expecting a block and which we cannot be easily sure is not dependent on other messages unde

> If one is trying to pass a block-like object to a message that is expecting a block and which we cannot be easily sure is not dependent on other messages under obscure conditions, is it not easier to extend from / inherit whatever class the blocks in Smalltalk use (i.e. the equivalent of Proc in Ruby)? For Smalltalkers this is just the difference between inheritance vs composition. Sometimes you don't want to directly inherit because your object's implementation of something like #value: is going to be quite different (ie, "mean" something different to the implementor -- but not necessarily the sender). By using composition over inheritance you avoid having to call the super's version, which would be something like: value: aParameter self doSomeInternalProcessingWith: aParameter. super value: aParameter. > Or is it that documentation of such methods explicitly mention that they support not just Smalltalk blocks but also other "valuables"? Yeah so you will see methods that look kind of like this: doSomethingWith: aValuable ^ self processStuff: aValuable value. Here the variable name in the definition hints to the reader what it should be like (this is common in Smalltalk). The "valuable" pattern-ish thing is not used super often as far as I've seen. Pharo uses it in composing Announcements and I think UI packages like the make use of it too.