[Pharo-project] [OffTopoc] Symbol understands value: nice hehehehehhe
Hi. Today I was giving a lesson and I was trying something something like this: ByteString allInstances select: [ :aString | aString size > 1000 ] But sometimes, we want (not in this example) delegate the behavior to the object, for example: ByteString allInstances select: [ :aString | aString isTooBig ] And then....I (actually, a classmate told me) realised that Symbol understands value: too. So I can do this: ByteString allInstances select: #isTooBig and it also works :) Interesting, isn't it ? cheers Mariano ps: if everybody already know this, please forgive my completly ignorance
Keep in mind that finding senders will be more difficult, and that you may or may not find the code you're looking for later if it is "non-standard" (e.g.: with the rewrite tool, you will have to search potentially many times to find all occurrences of a certain piece of code). Finally, with some constructs, using a symbol as a valuable may not always work as expected (e.g.: 1 to: 10 do: #squared). IMO, it looks cool, but in the long run it's more of a maintenance problem. On 10/30/10 13:01 , Mariano Martinez Peck wrote:
Hi. Today I was giving a lesson and I was trying something something like this:
ByteString allInstances select: [ :aString | aString size > 1000 ]
But sometimes, we want (not in this example) delegate the behavior to the object, for example:
ByteString allInstances select: [ :aString | aString isTooBig ]
And then....I (actually, a classmate told me) realised that Symbol understands value: too. So I can do this:
ByteString allInstances select: #isTooBig
and it also works :)
Interesting, isn't it ?
cheers
Mariano
ps: if everybody already know this, please forgive my completly ignorance
On Sat, Oct 30, 2010 at 5:10 PM, Andres Valloud < avalloud@smalltalk.comcastbiz.net> wrote:
Keep in mind that finding senders will be more difficult, and that you may or may not find the code you're looking for later if it is "non-standard" (e.g.: with the rewrite tool, you will have to search potentially many times to find all occurrences of a certain piece of code). Finally, with some constructs, using a symbol as a valuable may not always work as expected (e.g.: 1 to: 10 do: #squared).
IMO, it looks cool, but in the long run it's more of a maintenance problem.
100% agree. It was just funny for me, how could I do that, just implementing Synbol >> value: Just something curious and funny. Not to really use it.
On 10/30/10 13:01 , Mariano Martinez Peck wrote:
Hi. Today I was giving a lesson and I was trying something something like this:
ByteString allInstances select: [ :aString | aString size > 1000 ]
But sometimes, we want (not in this example) delegate the behavior to the object, for example:
ByteString allInstances select: [ :aString | aString isTooBig ]
And then....I (actually, a classmate told me) realised that Symbol understands value: too. So I can do this:
ByteString allInstances select: #isTooBig
and it also works :)
Interesting, isn't it ?
cheers
Mariano
ps: if everybody already know this, please forgive my completly ignorance
Mariano, On 10/30/10 13:14 , Mariano Martinez Peck wrote:
100% agree. It was just funny for me, how could I do that, just implementing Synbol >> value: Just something curious and funny. Not to really use it.
I agree with this, polymorphism is awesome. For instance, something I did with Assessments was to make objects polymorphic with classes. This device allows Assessments to run SUnit tests without needing to touch any of the test case classes (you can just create pseudo-classes that pretend to be the classes you need but can't have). And you get to implement #new on the instance side :). Andres.
We use this pattern in Mondrian scripts, Glamour scripts, and in Moose scripts for navigating models. However, we are most of the times doing it with other Symbol selectors. For example: - in Mondrian, we use moValue: - in Glamour, we use glamourValue: Using dedicated extensions enable us to control the kinds of semantics we want in the scripting. For example, the glamourValue: is different from moValue:. Cheers, Doru On 30 Oct 2010, at 22:56, Andres Valloud wrote:
Mariano,
On 10/30/10 13:14 , Mariano Martinez Peck wrote:
100% agree. It was just funny for me, how could I do that, just implementing Synbol >> value: Just something curious and funny. Not to really use it.
I agree with this, polymorphism is awesome. For instance, something I did with Assessments was to make objects polymorphic with classes. This device allows Assessments to run SUnit tests without needing to touch any of the test case classes (you can just create pseudo-classes that pretend to be the classes you need but can't have). And you get to implement #new on the instance side :).
Andres.
-- www.tudorgirba.com "Be rather willing to give than demanding to get."
I like the idea of using fooValue: instead of value:. On 10/30/10 14:15 , Tudor Girba wrote:
We use this pattern in Mondrian scripts, Glamour scripts, and in Moose scripts for navigating models.
However, we are most of the times doing it with other Symbol selectors. For example: - in Mondrian, we use moValue: - in Glamour, we use glamourValue:
Using dedicated extensions enable us to control the kinds of semantics we want in the scripting. For example, the glamourValue: is different from moValue:.
Cheers, Doru
On 30 Oct 2010, at 22:56, Andres Valloud wrote:
Mariano,
On 10/30/10 13:14 , Mariano Martinez Peck wrote:
100% agree. It was just funny for me, how could I do that, just implementing Synbol>> value: Just something curious and funny. Not to really use it.
I agree with this, polymorphism is awesome. For instance, something I did with Assessments was to make objects polymorphic with classes. This device allows Assessments to run SUnit tests without needing to touch any of the test case classes (you can just create pseudo-classes that pretend to be the classes you need but can't have). And you get to implement #new on the instance side :).
Andres.
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
.
participants (3)
-
Andres Valloud -
Mariano Martinez Peck -
Tudor Girba