Writing Extensions

[Kay C Lan]

And this is exactly why I love Switch, that I can use Case as an OR
statement whilst using soft wrap \ (CR) for making the script more
readable and understandable as the indenting is different.

My specific situation is I have 99 objects that I need to test. Some
are booleans, some integers, some date and times, some text. As you
can appreciate the possible variations of combination is a very large
number, but thankfully the outcomes fall nicely within a bell curve
and the responses to many 'groups' of conditions is the same. This is
where the discovery of Switch fall through was a godsend.

So I write my Switch statement like this:

switch
  --bell curve case 1
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99))
    myHandler1
  break
  --bell curve case 2
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99))
     myHandler2
  break
  case ....

  break
  default
    answer warning "A Case I have not considered." titled "Case Error"
    breakpoint
end switch

What this allows me to do is very quickly capture the middle of the
bell curve of all the 'known' expected cases, but ALWAYS stop at the
outliers - at which point I'll update the code as required.
Unfortunately as a single line it's VERY difficult to figure out the
difference between case 1 and 2 above because the actually difference
is way off the page. So I can use soft line break \ (CR) and a little
thought:

switch
  --bell curve case 1
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
    (myVar57 is true) AND (myVar82 is empty)) --the unique bits
    myHandler1
  break
  --bell curve case 2
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
     ((myVar33 <> 11) OR (myVar71 contains "uranium"))  --the unique bits
     myHandler2
  break
  case ...

  break
  default
    answer warning "A Case I have not considered." titled "Case Error"
    breakpoint
end switch

This then makes it very fast and easy to duplicate cases which are
very similar and require the same action, by simple Copy and Paste and
adjust the appropriate unique tests

switch
  --bell curve case 1
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
    (myVar57 is true) AND (myVar82 is empty)) --the unique bits
  --FALL THROUGH, an OR, many tests the same, needs to be handled as above
  --bell curve case 1a
  case ((myVar2 = myCondition2) AND (myVar3 < myCondition3) AND ...
(myVar99 contains myCondition99) AND \
    (myVar1 <> myCondition1) AND (myVar42 is an integer)) --the unique bits
    myHandler1
  break
  --bell curve case 2
  case ((myVar1 = myCondition1) AND (myVar2 < myCondition2) AND ...
(myVar99 contains myCondition99) AND \
     ((myVar33 <> 11) OR (myVar71 contains "uranium"))  --the unique bits
     myHandler2
  break
  case ...

  break
  default
    answer warning "A Case I have not considered." titled "Case Error"
    breakpoint
end switch

And the above is extremely simplistic compared to what I really have.
What I've shown as (myVar1 = myCondition1) AND (myVar2 < myCondition2)
in reality what appears within those bracketed AND statements are
usually multi-conditional OR tests themselves, each one long enough to
disappear off the screen before you get to the first AND! In one area
of the code I have well over 100 case () which fall through, and each
of those lines contains at least one soft wrap \ CR and sometimes more
if it's the contents of blocks of text that is unique. To replace the
fall through case () with a soft wrap OR \ which would then indent
exactly the same as what I've already formatted using soft wraps....
it just makes my brain hurt thinking about trying to unravel the mess
that would quickly become.

I appreciate my situation is probably extremely unique, but given the
opportunity to construct a new and improved Switch structure,  if fall
through is the problem then I'd make it clear that it is effectively
an OR, by using it as a keyword in the structure. I would also include
AND as a keyword even though 99.9% of the time it would seem
pointless. But trust me, when you are dealing with billions of
permutations, relying solely on soft wrap CRs \ is NOT VERY HELPFUL.

Having a new CHOOSE structure that auto indented on WHEN, OR, AND and
left you to use soft wrap \ CRs where you saw fit, I'm sure would help
create better blocks of code that would be easier to understand.

On Wed, May 24, 2017 at 11:11 PM, Mike Kerner via use-livecode
<use-livecode at lists.runrev.com> wrote:
> I personally hate switch.  That said, getting rid of the CR's would help
> make the new "choose" easier to read.  If you want a CR, use \
>
> choose tValue
>  when 1 or 2 or 3
>   -- do something
> end choose
>
> choose tValue
>  when 1\
>  or 2\
>  or 3
>   -- do something
> end choose
>
> On Wed, May 24, 2017 at 9:03 AM, Kay C Lan via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> On Wed, May 24, 2017 at 8:25 PM, Mark Waddingham via use-livecode
>> <use-livecode at lists.runrev.com> wrote:
>> >
>> Thanks Mark for the explanation.
>>
>> >   choose tValue
>> >     when 1
>> >     when 2
>> >     when 3
>> >       -- executes if tValue is 1, 2 or 3
>> >       -- never falls through
>> >
>> >     when 4
>> >       -- never falls through
>> >
>> >     default
>> >   end choose
>> >
>> > This caters for both cases (1) and (2) and is unambiguous.
>> >
>> Whilst I certainly like the above and think it an improvement, if I
>> were to 'step back' and redesign Switch I think I'd make it clearer
>> that 'fall through' is just an OR - it took me ages to realise and
>> I've have very very long: case ((....) OR (....) OR (....) ....) which
>> were extremely long and very hard to read until I rewrote them as
>>
>> case
>> case
>> case
>> case
>> ---do something
>> break
>>
>> What I can't currently solve is the many case ((.....) AND (,,,,) AND
>> (....) AND (...)... )
>>
>> So, again if I were reinventing Switch:
>>
>> choose tVale
>>   when 1
>>   or 2
>>   or 3
>>     --do something
>>     -- no further fall through
>>   when > 6
>>   and < 60
>>   and even
>>     --do something else
>>     --no further fall through
>>   when 4
>>     --do another thing
>>   default
>>     --some other thing
>> end choose
>>
>> Just makes it clear that fall through is being used to combine the
>> statements, but in my design it isn't just restricted to OR.
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode