Smalltalk › Instantiations

Case on http://vastgoodies.com

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Louis LaBrunda

Case on http://vastgoodies.com

Hi Everybody,

I have just published a Case class on VAST Goodies in KscCase. The Case Class is an attempt to create a Case type language construct in Smalltalk. It is patterned after the IBM Rexx language Select statement. In many languages, the case statement tests a single variable for different values and executes the code that corresponds to the variables value. The Rexx Select statement is more general and tests many conditions supplied by "When/Then" pairs and executes the statement following the "Then" clause that matches the "When" condition that evaluated to true.

This Case Class works in a similar manor. The "if:then:" message supplies condition value (boolean) or block and execute block pairs. With each "if:then:" message the condition is evaluated until one

is found to be true, its corresponding execute block is saved. If none of the "if:" conditions evaluate to true no execute block will have been saved and the instance variable will be nil. When an "otherwise:" message is received the saved execute block is tested for nil. If it is not nil its #value is returned. If it is nil the #value of the execute block associated with the "otherwise:" message is returned.

By cascading #if:then: messages there is the appearance of Smalltalk having a case statement when in reality Smalltalk is just sending messages like it always does.

I have read that case statements are not really "Smalltalk like" whatever that means. Many of my programs send messages in the very old style of strings in fixed locations within the message. The value of the strings are very much dependent on customer business needs that are often quite odd. Like if it is Tuesday and has grandma had breakfast in one part of the test and then something completely unrelated in an other part. Things like this:

market := Case of

if: [marketCapacity notEmpty] then: [marketCapacity first asString];

if: [isBalanceOrder] then: ['O'];

if: [contra isEmpty] then: ['O'];

otherwise: ['N'].

capacity := Case of

if: [isBalanceOrder] then: ['B'];

if: [marketCapacity size > 1] then: [marketCapacity second asString];

if: [contra isEmpty] then: ['D'];

otherwise: ['2'].

marketCapacity := market, capacity.

I find this case statement (class) very useful and easy to read.

I am curious what the group thinks about case statements and Smalltalk.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Richard Sargent

Re: Case on http://vastgoodies.com

Administrator

On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:

...

I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

jtuchel

Re: Case on http://vastgoodies.com

Hi Richard,

the way I understand Lou's code and what you suggest as a better approach are essentially the same thing. A "rule" chooser" would hold a list of associated blocks, one to test a condition, another one that is used to handle the situation if the condition block evaluates to true, right?

Your "rule selector" is another beast, and I must admit I also thought about how to use something like break; (or, the opposite thereof) in Lou's Case. I mean, how could I control that more than one case is true? Even the rule selector has one drawback: what if you want a selector, but there are cases in which the rule selector should not look for further cases?

Lou's Case could even be extended to handle at least the two variants easily by replacing the "of" class method with a pair of messages like "exclusivelyOf" and "noneExclusivleyOf" (Sorry, I have no better idea for the names right now, maybe a native english speaker could come up with better names).

Then, there is the option of handing the Case instance into the handling block for a statement, which could be used to implement the "break" semantics.

Like this:

capacity := Case noneExclusivelyOf

if: [isBalanceOrder] then: [:ruleset| ruleset doNotCheckFurtherCases. 'B']; "The break statement"

if: [marketCapacity size > 1] then: [marketCapacity second asString];

if: [contra isEmpty] then: ['D'];

otherwise: ['2'].

I must say I like the idea of having a chance to handle completely unrelated cases in one case/switch construct. Business rules can be very programmer-unfriendly, right? I've seen methods with conditionals that are very hard to understand because people tried to press very complex and partly unrelated things into an ifTrue:ifFalse: corset.

Joachim

Am Dienstag, 18. November 2014 01:10:54 UTC+1 schrieb Richard Sargent:

On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

Louis LaBrunda

Re: Case on http://vastgoodies.com

In reply to this post by Richard Sargent

Hi Richard,

Thanks for your thoughts.

On Monday, November 17, 2014 7:10:54 PM UTC-5, Richard Sargent wrote:

On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

My example was the first simple one I could find and was meant more to show what the Case statement would look like and not so much to justify its use.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

I think this Case class is a simple example of a rule chooser. It just doesn't hold all the conditions/tests/rule-objects and result blocks within itself and the business needs don't require it to. The business needs also don't require knowing why the rule applied, there is just no place for that information to go.

I think this is a case of TSTTCPW.

Lou

Louis LaBrunda

Re: Case on http://vastgoodies.com

In reply to this post by jtuchel

Hi Joachim,

Thanks for your thoughts and support.

On Tuesday, November 18, 2014 2:56:57 AM UTC-5, Joachim Tuchel wrote:

Hi Richard,

the way I understand Lou's code and what you suggest as a better approach are essentially the same thing. A "rule" chooser" would hold a list of associated blocks, one to test a condition, another one that is used to handle the situation if the condition block evaluates to true, right?

I think so too.

Your "rule selector" is another beast, and I must admit I also thought about how to use something like break; (or, the opposite thereof) in Lou's Case. I mean, how could I control that more than one case is true? Even the rule selector has one drawback: what if you want a selector, but there are cases in which the rule selector should not look for further cases?

Lou's Case could even be extended to handle at least the two variants easily by replacing the "of" class method with a pair of messages like "exclusivelyOf" and "noneExclusivleyOf" (Sorry, I have no better idea for the names right now, maybe a native english speaker could come up with better names).

Then, there is the option of handing the Case instance into the handling block for a statement, which could be used to implement the "break" semantics.
Like this:

capacity := Case noneExclusivelyOf
if: [isBalanceOrder] then: [:ruleset| ruleset doNotCheckFurtherCases. 'B']; "The break statement"
if: [marketCapacity size > 1] then: [marketCapacity second asString];
if: [contra isEmpty] then: ['D'];
otherwise: ['2'].

Joachim, my friend, I appreciate the support but here it seems you are over thinking things a bit. The Case statement is about executing "only" the first condition the is true and none after that. If more can be true and you want to execute them, a series of #ifTrue: is better. All that are true will execute, all that aren't won't. The nice thing about the case statement is that its intentions are clear. All the tests are together along with what to do when one is true and there is no need to set any flag to avoid execution anything after the first one found to be true. To my eye it is clean and simple, easy to read and understand, very much in the spirit of Smalltalk.

I must say I like the idea of having a chance to handle completely unrelated cases in one case/switch construct. Business rules can be very programmer-unfriendly, right? I've seen methods with conditionals that are very hard to understand because people tried to press very complex and partly unrelated things into an ifTrue:ifFalse: corset.

Exactly. This is also very much in the spirit of Smalltalk. Because the Case class is a class and not embedded in syntax somehow and because we have blocks of code that are objects and can be passed around, it becomes very simple to build and use. Try to make a case class in Java (not that I know much about Java but why its creators would copy Smalltalk and throw out blocks of code is beyond me).

Lou

Joachim

Am Dienstag, 18. November 2014 01:10:54 UTC+1 schrieb Richard Sargent:
On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

Richard Sargent

Re: Case on http://vastgoodies.com

Administrator

In reply to this post by jtuchel

On Monday, November 17, 2014 11:56:57 PM UTC-8, Joachim Tuchel wrote:

the way I understand Lou's code and what you suggest as a better approach are essentially the same thing. A "rule" chooser" would hold a list of associated blocks, one to test a condition, another one that is used to handle the situation if the condition block evaluates to true, right?

Umm, no. Rules are first class objects with potential inheritance, so they can share the expression of common conditions (and implement specific facets differently, if necessary). When you "choose the one rule", that's what you end up with. What you do with it after that depends on what you programmed it to do, whether that is to answer a specific values to various message sends or whether to perform some kind of action or actions against the domain model. The condition and outcome are connected, because they are modelled as a single class. A rule chooser answers exactly one rule, so the first satisfied rule is the one answered.

Your "rule selector" is another beast, and I must admit I also thought about how to use something like break; (or, the opposite thereof) in Lou's Case. I mean, how could I control that more than one case is true? Even the rule selector has one drawback: what if you want a selector, but there are cases in which the rule selector should not look for further cases?

I made a typo in the name of rule selector. I should have written "rules selector". It answers zero or more satisfied rules, each of which implements any number of methods to provide whatever outcome you design.

Lou's Case could even be extended to handle at least the two variants easily by replacing the "of" class method with a pair of messages like "exclusivelyOf" and "noneExclusivleyOf" (Sorry, I have no better idea for the names right now, maybe a native english speaker could come up with better names).

Then, there is the option of ...

I wouldn't. In my opinion, the Case construct will not scale very well; adding baggage will just exacerbate that. Re-read your next paragraph. :-)

I must say I like the idea of having a chance to handle completely unrelated cases in one case/switch construct. Business rules can be very programmer-unfriendly, right? I've seen methods with conditionals that are very hard to understand because people tried to press very complex and partly unrelated things into an ifTrue:ifFalse: corset.

The case construct is a little more succinct that ifTrue:/ifFalse: trees, but not enough. How readable will a case with 50 clauses be? With 10 when the conditions and outcomes are complex? How well will it suffice to *document* the complexity of those business rules? Consider instead a suite of related classes (using my insurance quote example). When you look at the subset of rules covering just New Hampshire's under-insured motorist coverage, each permutation can be clearly documented by the class implementing the rule. The business decides they need another variation? No big deal; you get to leverage all the other related rules.

Joachim

Am Dienstag, 18. November 2014 01:10:54 UTC+1 schrieb Richard Sargent:
On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

Richard Sargent

Re: Case on http://vastgoodies.com

Administrator

In reply to this post by Louis LaBrunda

On Tuesday, November 18, 2014 6:45:48 AM UTC-8, Louis LaBrunda wrote:

Hi Richard,

Thanks for your thoughts.

On Monday, November 17, 2014 7:10:54 PM UTC-5, Richard Sargent wrote:
On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

My example was the first simple one I could find and was meant more to show what the Case statement would look like and not so much to justify its use.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

I think this Case class is a simple example of a rule chooser. It just doesn't hold all the conditions/tests/rule-objects and result blocks within itself and the business needs don't require it to. The business needs also don't require knowing why the rule applied, there is just no place for that information to go.

I think this is a case of TSTTCPW.

I think you have just supported my argument. I said that the Case construct would be reasonable in simple situations. I implied it won't scale well, and in my opinion, it is harder to diagnose when things don't seem to work as intended.

Lou

Louis LaBrunda

Re: Case on http://vastgoodies.com

On Tuesday, November 18, 2014 11:47:12 AM UTC-5, Richard Sargent wrote:

On Tuesday, November 18, 2014 6:45:48 AM UTC-8, Louis LaBrunda wrote:
Hi Richard,

Thanks for your thoughts.

On Monday, November 17, 2014 7:10:54 PM UTC-5, Richard Sargent wrote:
On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

My example was the first simple one I could find and was meant more to show what the Case statement would look like and not so much to justify its use.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

I think this Case class is a simple example of a rule chooser. It just doesn't hold all the conditions/tests/rule-objects and result blocks within itself and the business needs don't require it to. The business needs also don't require knowing why the rule applied, there is just no place for that information to go.

I think this is a case of TSTTCPW.

I think you have just supported my argument. I said that the Case construct would be reasonable in simple situations. I implied it won't scale well, and in my opinion, it is harder to diagnose when things don't seem to work as intended.

I do support your argument, at least most of it. A rules selector would scale better than my Case class but my Case class is intended for the simpler cases where you want to see the rules right there in the code and not have to go look somewhere else where the rules selector is being filled with rules. If there was a rules selector available either from Instantiations or on VAST Goodies, I probably would have started with it. But since there isn't and since I don't have a need to a full blown rules selector and don't like to write code I don't need yet or fully understand some future need, I decided to just go with the Case class.

If I had a rules selector I probably would have sub-classed it and called the subclass Case. I then would have written methods like #addRule:withAction: and #selectFirstRuleAndExecuteItOr:. Then I could add the rules to the rules selector in line where I can see them. Yes, I would limit this use to a handful of rules but that is exactly what I want, something cleaner than a bunch of #ifTrue:'s and still right there in the code.

I may even have named the methods #if:then: and #otherwise: and been right back to my Case class. As much as the Case class won't scale well up to 50 rules, using a proper rules selector for these simple cases seems like overkill. I think the Smalltalk world has room for both.

Thank you for your comments, it has been interesting thinking about this. I even find myself looking forward to a day when I might need a rules selector and using/building one.

Lou

Lou

Richard Sargent

Re: Case on http://vastgoodies.com

Administrator

On Thursday, November 20, 2014 7:25:39 AM UTC-8, Louis LaBrunda wrote:

On Tuesday, November 18, 2014 11:47:12 AM UTC-5, Richard Sargent wrote:
On Tuesday, November 18, 2014 6:45:48 AM UTC-8, Louis LaBrunda wrote:
Hi Richard,

Thanks for your thoughts.

On Monday, November 17, 2014 7:10:54 PM UTC-5, Richard Sargent wrote:
On Monday, November 17, 2014 12:31:24 PM UTC-8, Louis LaBrunda wrote:
...
I have read that case statements are not really "Smalltalk like" whatever that means.
...
I am curious what the group thinks about case statements and Smalltalk.

Rather than say they are "not really Smalltalk-like", I prefer to think of them as not very object oriented. But sometimes it is difficult to get from something that isn't represented by different classes to an object oriented solution. You examples appear to support this.

My example was the first simple one I could find and was meant more to show what the Case statement would look like and not so much to justify its use.

In general, I am not opposed to simple cases like this (no pun intended!), but I am extremely wary of 'simple' turning into complex. One colleague liked to use the term "attractive nuisance" for things that could suck the unwary into a trap. I feel the case class has this potential.

There are better approaches when the situation is more complex or when you want to do more than your example shows. In such scenarios, a "rule chooser" can give a better result.
[A rule chooser is analogous to a #detect: among a collection of rule instances which operate against a shared context object. Each rule can answer whether it applies to the context and can answer a result or act on the domain model in some fashion. Rule objects can also explain why they apply, which is useful for diagnosing surprising behaviour.
A variation on a rule chooser is a rule selector, which is analogous to a #select: in which 0 or more rules may apply. An example of where this might be useful would be in configuring the initial quote of auto insurance, in which different states have different coverages, different rules for when a coverage can be used, and where the business has different rules for deciding what coverages to quote initially e.g. depending on the age of the car or the drivers, etc.]

I think this Case class is a simple example of a rule chooser. It just doesn't hold all the conditions/tests/rule-objects and result blocks within itself and the business needs don't require it to. The business needs also don't require knowing why the rule applied, there is just no place for that information to go.

I think this is a case of TSTTCPW.

I think you have just supported my argument. I said that the Case construct would be reasonable in simple situations. I implied it won't scale well, and in my opinion, it is harder to diagnose when things don't seem to work as intended.

I do support your argument, at least most of it. A rules selector would scale better than my Case class but my Case class is intended for the simpler cases where you want to see the rules right there in the code and not have to go look somewhere else where the rules selector is being filled with rules. If there was a rules selector available either from Instantiations or on <a href="http://vastgoodies.com" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fvastgoodies.com\46sa\75D\46sntz\0751\46usg\75AFQjCNHxjcEL5lPg-RJkLXxK7FrDTlALcw';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fvastgoodies.com\46sa\75D\46sntz\0751\46usg\75AFQjCNHxjcEL5lPg-RJkLXxK7FrDTlALcw';return true;">VAST Goodies, I probably would have started with it. But since there isn't and since I don't have a need to a full blown rules selector and don't like to write code I don't need yet or fully understand some future need, I decided to just go with the Case class.

If I had a rules selector I probably would have sub-classed it and called the subclass Case. I then would have written methods like #addRule:withAction: and #selectFirstRuleAndExecuteItOr:. Then I could add the rules to the rules selector in line where I can see them. Yes, I would limit this use to a handful of rules but that is exactly what I want, something cleaner than a bunch of #ifTrue:'s and still right there in the code.

I may even have named the methods #if:then: and #otherwise: and been right back to my Case class. As much as the Case class won't scale well up to 50 rules, using a proper rules selector for these simple cases seems like overkill. I think the Smalltalk world has room for both.

Thank you for your comments, it has been interesting thinking about this. I even find myself looking forward to a day when I might need a rules selector and using/building one.

Lou

Lou

The abstraction for a Rule Chooser and a Rules Selector is pretty simple. I'll see if I can find the UML I put together years ago to document it. If I still have it, I'll post it here. It definitely helps manage complexity for the more complicated sets of rules one might encounter.

Louis LaBrunda

Re: Case on http://vastgoodies.com

Hey Richard,

The abstraction for a Rule Chooser and a Rules Selector is pretty simple. I'll see if I can find the UML I put together years ago to document it. If I still have it, I'll post it here. It definitely helps manage complexity for the more complicated sets of rules one might encounter.

That would be great, even if I don't have a need for it at the moment, someone else might. I also encourage you to post the code on VAST Goodies if you can.

Lou

Louis LaBrunda

Re: Case on http://vastgoodies.com

In reply to this post by jtuchel

Hey Joachim,

I think I may have misunderstood what you were saying. I see now (I think) that you were talking about extending my Case class to being more of a rule chooser or selector. Anyway I hope you weren't offended by anything I said, certainly no offense was intended. And I hope you will get a chance to try my Case class.

Lou

On Tuesday, November 18, 2014 2:56:57 AM UTC-5, Joachim Tuchel wrote:

Hi Richard,

the way I understand Lou's code and what you suggest as a better approach are essentially the same thing. A "rule" chooser" would hold a list of associated blocks, one to test a condition, another one that is used to handle the situation if the condition block evaluates to true, right?

Your "rule selector" is another beast, and I must admit I also thought about how to use something like break; (or, the opposite thereof) in Lou's Case. I mean, how could I control that more than one case is true? Even the rule selector has one drawback: what if you want a selector, but there are cases in which the rule selector should not look for further cases?

Lou's Case could even be extended to handle at least the two variants easily by replacing the "of" class method with a pair of messages like "exclusivelyOf" and "noneExclusivleyOf" (Sorry, I have no better idea for the names right now, maybe a native english speaker could come up with better names).

Then, there is the option of handing the Case instance into the handling block for a statement, which could be used to implement the "break" semantics.
Like this:

capacity := Case noneExclusivelyOf
if: [isBalanceOrder] then: [:ruleset| ruleset doNotCheckFurtherCases. 'B']; "The break statement"
if: [marketCapacity size > 1] then: [marketCapacity second asString];
if: [contra isEmpty] then: ['D'];
otherwise: ['2'].

I must say I like the idea of having a chance to handle completely unrelated cases in one case/switch construct. Business rules can be very programmer-unfriendly, right? I've seen methods with conditionals that are very hard to understand because people tried to press very complex and partly unrelated things into an ifTrue:ifFalse: corset.

Joachim

Richard Sargent

Re: Case on http://vastgoodies.com

Administrator

In reply to this post by Richard Sargent

On Thursday, November 20, 2014 8:45:36 AM UTC-8, Richard Sargent wrote:

The abstraction for a Rule Chooser and a Rules Selector is pretty simple. I'll see if I can find the UML I put together years ago to document it. If I still have it, I'll post it here. It definitely helps manage complexity for the more complicated sets of rules one might encounter.

The attached PDF should show how the rule chooser/selector is structured. As mentioned before, this pattern's strength lies in complicated sets of rules. For simple scenarios, it may be over-kill. (But we all know how easily simple scenarios evolve into complicated ones.)

Rule Patterns.pdf (121K) Download Attachment

Louis LaBrunda

Re: Case on http://vastgoodies.com

Hi Richard,

Thanks for this. I don't have an immediate need but I will tuck it away for future reference.

Lou

On Sunday, November 23, 2014 7:29:16 PM UTC-5, Richard Sargent wrote:

On Thursday, November 20, 2014 8:45:36 AM UTC-8, Richard Sargent wrote:
The abstraction for a Rule Chooser and a Rules Selector is pretty simple. I'll see if I can find the UML I put together years ago to document it. If I still have it, I'll post it here. It definitely helps manage complexity for the more complicated sets of rules one might encounter.

The attached PDF should show how the rule chooser/selector is structured. As mentioned before, this pattern's strength lies in complicated sets of rules. For simple scenarios, it may be over-kill. (But we all know how easily simple scenarios evolve into complicated ones.)