3 ms·

> Are there not other messages that they might depend on that would also need to be implemented? The answer to this is "maybe" but it doesn't really matter. Yo

by scroot 7y ago

> Are there not other messages that they might depend on that would also need to be implemented? The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. We can think of this as some kind of delayed evaluation. Perhaps we define an object who, when sent the #value message, goes off and fetches information from the net or something. We wait until the #value message is sent before doing so, just like we wait to evaluate a block until #value is sent. An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process.

jolmg 7y ago
> The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. 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)? Or is it that documentation of such methods explicitly mention that they support not just Smalltalk blocks but also other "valuables"? > An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process. I mean, sure, you can intuitively guess that such messages might not be needed, but it might not always be such an easy thing to guess. Ruby Procs have the methods `arity` and `parameters` for example, which could be widely used to inspect the parameters accepted by a block to decide how to pass arguments in. I never used such methods, but it might be that methods from other libraries to which I pass these blocks could use them. I don't know. I guess it could be a language culture thing. Dependence on only `#value` / `#value:` could be common convention in Smalltalk if usage of valuables is a more common idiom.
- scroot 7y ago
  > 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.

by scroot 7y ago

jolmg 7y ago

> The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. 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)? Or is it that documentation of such methods explicitly mention that they support not just Smalltalk blocks but also other "valuables"? > An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process. I mean, sure, you can intuitively guess that such messages might not be needed, but it might not always be such an easy thing to guess. Ruby Procs have the methods `arity` and `parameters` for example, which could be widely used to inspect the parameters accepted by a block to decide how to pass arguments in. I never used such methods, but it might be that methods from other libraries to which I pass these blocks could use them. I don't know. I guess it could be a language culture thing. Dependence on only `#value` / `#value:` could be common convention in Smalltalk if usage of valuables is a more common idiom.

scroot 7y ago
> 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.