Re: common code patterns

[Sannyasin Brahmanathaswami via use-livecode]

Yes

On 8/10/17, 2:42 PM, "use-livecode on behalf of Monte Goulding via 
use-livecode"  wrote:

local s

command set p
   put p into s
end set

function get
   return s
end get

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Bob Sneidar via use-livecode]

I'm at a loss here. What do you mean by multi-line strings besides strings with 
multiple lines in them? Isn't this already possible??

Bob S


> On Aug 14, 2017, at 09:00 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/14/2017 03:28 AM, Alex Tweedly via use-livecode wrote:
>> While we (i.e. you) are thinking about string delimiters, could we PLEASE 
>> have some decent way to do multi-line strings.
> 
> Yes, please.
> 
>> Whether it's like Python's triple-quote
> 
> No, please.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Monte Goulding via use-livecode]

> On 15 Aug 2017, at 7:33 am, Monte Goulding via use-livecode 
>  wrote:
> 
> put “foo\
> bar”
> 
> would put:
> 
> foo
> bar

I had a little play while munching my muesli this morning with adding this to 
my (probably won’t get in the engine) PR for escaped strings. It was only a few 
lines to add but I didn’t look at colorization yet. I put a gif up here 
https://github.com/livecode/livecode/pull/5781 


Of course that is:

put ‘foo\
  bar’

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Monte Goulding via use-livecode]

> On 15 Aug 2017, at 5:22 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> put {{
> That's better!
> A really readable and short
> version that I can deal with.
> }} into temp

It’s really unlikely we would use { } because one day we will want to implement 
array literals. You know one time I messed with the server tag code in the 
parser so that reverse server tags could be used for this ;-)

http://forums.livecode.com/viewtopic.php?f=66=25339 


That of course would never pass the sniff test!

Anyway, if I might propose an alternative of allowing the line continuation 
char (which happens to be escape) within strings. The sequence \ & return & 
 would be replaced with just return in the string.

Something like this:

put “foo\
 bar”

would put:

foo
bar

Of course if you need leading whitespace then that’s a bit trickier but the 
above could be relatively easily implemented in both the script editor and the 
parser.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 15 Aug 2017, at 2:10 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> But maybe not enough markdown to change how the human eye works. :)

Sure, my preferable end goal does not include backticks but I’ll take anything 
if it’s the only way I can have a string with escapes ;-)

The conclusion I came to on the bug report is we should have a goal of 
supporting escapes in all string forms (like JavaScript) but that we can’t do 
double quote yet due to backwards compatibility. That would come with open 
language which will have a script translation step and one of those steps can 
be “\” -> “\\” everywhere but format et al. For readability we would like a 
single quote delimited string so that it can include double quotes. If we add a 
single quote delimited string it can have escapes now because it’s something 
new. So we would have a few years of single quote delimited strings that 
process escape sequences and double quoted strings that don’t but eventually 
all would.

As far as interpolation goes I think I can live with the merge function 
particularly if I can pass it a string with escape sequences:

put “Hello" into tFoo
put “World” into tBar
put merge(‘[[ tFoo ]]\n[[ tBar ]]!’)

Cheers

Monte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Alex Tweedly via use-livecode]

If you mean, do I think

put \
"This is part of" & \
"A multi-line string which" & \
"I find much less readable." into temp

is less preferable than

put {{
That's better!
A really readable and short
version that I can deal with.
}} into temp

then, Yes - absolutely.

To be honest, I don't much care whether it's triple-quote (not my 
favourite), or {{...}}, or < wrote:


On 08/14/2017 03:28 AM, Alex Tweedly via use-livecode wrote:


While we (i.e. you) are thinking about string delimiters, could we PLEASE
have some decent way to do multi-line strings.


Yes, please.



Whether it's like Python's triple-quote


No, please.

--
  Mark Wieder
  ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode







___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Richard Gaskin via use-livecode]

Bob Hall wrote:

>> On Aug 14, 2017, at 6:28 AM, Alex Tweedly wrote:
>>
>> While we (i.e. you) are thinking about string delimiters, could we
>> PLEASE have some decent way to do multi-line strings.
>
> I find myself in many situations where multi-line strings would make
> my code so much more readable. I do a lot of database work and having
> a multi-line string for defining queries would be great.
>
> I used to put my queries in custom props (easier to read/modify) but
> I’m finding now that I’d rather have the definitions in script-only
> stacks and get them under source control. However, the current method
> of appending multi-line strings together makes the code difficult to
> work with and read.
>
> So I’ll +1 this request. I’d lean toward the triple-quote syntax for
> implementation.

A while back I proposed some form of bash's heredoc - I'm not enamored 
of the name, but the concept seems useful:


http://quality.livecode.com/show_bug.cgi?id=17471

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Bob Hall via use-livecode]

> On Aug 14, 2017, at 6:28 AM, Alex Tweedly via use-livecode 
>  wrote:
> 
> While we (i.e. you) are thinking about string delimiters, could we PLEASE 
> have some decent way to do multi-line strings.

I find myself in many situations where multi-line strings would make my code so 
much more readable. I do a lot of database work and having a multi-line string 
for defining queries would be great. 

I used to put my queries in custom props (easier to read/modify) but I’m 
finding now that I’d rather have the definitions in script-only stacks and get 
them under source control. However, the current method of appending multi-line 
strings together makes the code difficult to work with and read.

So I’ll +1 this request. I’d lean toward the triple-quote syntax for 
implementation.

Bob Hall

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Mike Kerner via use-livecode]

So you don't like & ?

On Mon, Aug 14, 2017 at 12:00 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/14/2017 03:28 AM, Alex Tweedly via use-livecode wrote:
>
>> While we (i.e. you) are thinking about string delimiters, could we PLEASE
>> have some decent way to do multi-line strings.
>>
>
> Yes, please.
>
>
>> Whether it's like Python's triple-quote
>>
>
> No, please.
>
> --
>  Mark Wieder
>  ahsoftw...@gmail.com
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

>> On 14 Aug 2017, at 5:45 pm, Mark Waddingham wrote:
>>
>> P.S. There is another quote-like char which could be used for
>> an implicitly merged / escaped string literal - back-quote -
>> `...`. So that should be considered too - one option would be
>> single-quote and double-quote delimited strings are the same
>> beyond the quote char; but back-quote delimited strings do
>> more work, i.e. de-escape and potentially interpolate. (Of
>> course, this does add *more* symbols to the language - but
>> one thing symbols are good for is readable bracketing, so maybe
>> that's a good justification).
>
> Haha… to quote you some 4 years ago after I suggested backtick:
>
>> Oh, please not backtick! The character is awkward to type (its one
>> of the ones that moves around a lot on keyboard layouts) and
>> difficult to read (and always makes me think something more is
>> going on - e.g. as in bash scripts!).
>
> Mind you we have all written a _lot_ of markdown since then so
> backtick is probably much more palatable.

But maybe not enough markdown to change how the human eye works. :)

I agree with MW's original assessment.

If we have a problem to solve for which no alternative is possible, I'd 
accept using backticks for some things.  But at least as far as my 
original request, and anything else I can conceive of offhand, I would 
prefer to avoid them for the reasons MW noted.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/14/2017 02:35 AM, Mark Waddingham via use-livecode wrote:

slight 'yak-shave' here with regards constants 
(http://quality.livecode.com/show_bug.cgi?id=19413) - as anything after 
an initializer is currently treated as a literal, and *not* an expression.


...and not just 19413. This request has been around since 2004.
http://quality.livecode.com/show_bug.cgi?id=1241

actually figure out the whys and wherefores - and choose some colors for 
all the bike-sheds which don't cause anyone too much nausea!


Metaphors aside, I like where this conversation is heading.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: String delimiters [WAS Re: common code patterns]

[Mark Wieder via use-livecode]

On 08/14/2017 03:28 AM, Alex Tweedly via use-livecode wrote:
While we (i.e. you) are thinking about string delimiters, could we 
PLEASE have some decent way to do multi-line strings.


Yes, please.



Whether it's like Python's triple-quote


No, please.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Bob Sneidar via use-livecode]

put "Hello there, Teddy Roughrider Roosevelt!" into tText
replace "Roughrider" with quote & "Roughrider" & quote in tText

Bob S


> On Aug 12, 2017, at 13:20 , Richard Gaskin via use-livecode 
>  wrote:
> 
> The q function is handy, but handier still would be to have JavaScript's 
> support for interchangeable single- and double-quotes to allow nesting, e.g.:
> 
>  put 'Hello there, Teddy "Roughrider" Roosevelt!'
> 
> -- 
> Richard Gaskin


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

String delimiters [WAS Re: common code patterns]

[Alex Tweedly via use-livecode]

While we (i.e. you) are thinking about string delimiters, could we 
PLEASE have some decent way to do multi-line strings.


Whether it's like Python's triple-quote, or Perl's heredoc, or  just 
some way to do them without either escaped '\n's or non-embedded CRs.


Thanks

Alex.


On 14/08/2017 10:35, Mark Waddingham via use-livecode wrote:

On 2017-08-14 11:14, Monte Goulding via use-livecode wrote:

Hmm… so say merge(“ string “, resolve escapes) = ` string ` ? I’ve got
to say I wasn’t thinking of interpolation as I thought that merge does
that sufficiently well.


Seeing 'special tokens' as syntactic sugar is definitely the way to go 
I think - it means that these escaping / interpolation operations are 
available for direct use form code, as well as when they are embedded 
(as tokens) in code.


Merge does do interpolation reasonably well, but it does not do 
escaping. In contrast format does escaping and formatting, but not 
interpolation. Escaping, formatting and interpolation are all part of 
a 'similar' idea - and they are unified into a single thing in many 
other languages so it would perhaps make sense for them to be so in 
LiveCode too.


Of course, strictly speaking they are separate operations - 
interpolation requires more machinery than formatting which requires 
more machinery than escaping. However, cognitively, being able to do 
them all in a single unified string format does perhaps have a lot of 
value - and makes what is a 'slightly more complex' set of operations, 
'slightly easier' to grok.


[ Indeed, 'under the hood' the best way to look at it is that 
interpolation is transformed to format which then uses unescaping 
before filling in the placeholders ]




However, there are other options too - at the end of the day is 
'format("...")' actually too onerous on occasions you want escaping?


Yes, unless you can use it in a constant or variable declaration which
would be unusual and a bit too special casey for me:

constant kSomething = format(“this\tis\todd”)


I'm not sure I see why it would be 'special-casey' in particular. The 
mechanism we need to do this is universal - i.e. would apply to 
constant inputs to any pure/constant function. There is of course (as 
always) a slight 'yak-shave' here with regards constants 
(http://quality.livecode.com/show_bug.cgi?id=19413) - as anything 
after an initializer is currently treated as a literal, and *not* an 
expression.


The thought I'm having along this line is that 'easy things should be 
easy' and 'hard things should be possible'. i.e. The complexity of the 
syntax should reflect the complexity of the operation. There seems to 
be significant value in *just* having " and ' be plain strings - which 
suggests that perhaps escaping/interpolation should require slightly 
different syntax (and be perhaps slightly more verbose).



Sure if you it’s a priority. The PR is only up there because I got
interested in something on a rainy Sunday arvo. It’s not like we
haven’t got other stuff to do and this bike shed seems to be rather
large ;-)


It is certainly 'important' as far as working out what the best 
approach is. After all, if we can break things down into small 
bite-sized chunks heading towards what a generally considered 
reasonable goal, then it means it is more likely to happen over time 
(particularly as each bite-sized chunk probably has other fringe 
benefits). The idea(s) and such have been hanging around for long 
enough, it would be good to actually figure out the whys and 
wherefores - and choose some colors for all the bike-sheds which don't 
cause anyone too much nausea!


Warmest Regards,

Mark.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-14 11:14, Monte Goulding via use-livecode wrote:

Hmm… so say merge(“ string “, resolve escapes) = ` string ` ? I’ve got
to say I wasn’t thinking of interpolation as I thought that merge does
that sufficiently well.


Seeing 'special tokens' as syntactic sugar is definitely the way to go I 
think - it means that these escaping / interpolation operations are 
available for direct use form code, as well as when they are embedded 
(as tokens) in code.


Merge does do interpolation reasonably well, but it does not do 
escaping. In contrast format does escaping and formatting, but not 
interpolation. Escaping, formatting and interpolation are all part of a 
'similar' idea - and they are unified into a single thing in many other 
languages so it would perhaps make sense for them to be so in LiveCode 
too.


Of course, strictly speaking they are separate operations - 
interpolation requires more machinery than formatting which requires 
more machinery than escaping. However, cognitively, being able to do 
them all in a single unified string format does perhaps have a lot of 
value - and makes what is a 'slightly more complex' set of operations, 
'slightly easier' to grok.


[ Indeed, 'under the hood' the best way to look at it is that 
interpolation is transformed to format which then uses unescaping before 
filling in the placeholders ]




However, there are other options too - at the end of the day is 
'format("...")' actually too onerous on occasions you want escaping?


Yes, unless you can use it in a constant or variable declaration which
would be unusual and a bit too special casey for me:

constant kSomething = format(“this\tis\todd”)


I'm not sure I see why it would be 'special-casey' in particular. The 
mechanism we need to do this is universal - i.e. would apply to constant 
inputs to any pure/constant function. There is of course (as always) a 
slight 'yak-shave' here with regards constants 
(http://quality.livecode.com/show_bug.cgi?id=19413) - as anything after 
an initializer is currently treated as a literal, and *not* an 
expression.


The thought I'm having along this line is that 'easy things should be 
easy' and 'hard things should be possible'. i.e. The complexity of the 
syntax should reflect the complexity of the operation. There seems to be 
significant value in *just* having " and ' be plain strings - which 
suggests that perhaps escaping/interpolation should require slightly 
different syntax (and be perhaps slightly more verbose).



Sure if you it’s a priority. The PR is only up there because I got
interested in something on a rainy Sunday arvo. It’s not like we
haven’t got other stuff to do and this bike shed seems to be rather
large ;-)


It is certainly 'important' as far as working out what the best approach 
is. After all, if we can break things down into small bite-sized chunks 
heading towards what a generally considered reasonable goal, then it 
means it is more likely to happen over time (particularly as each 
bite-sized chunk probably has other fringe benefits). The idea(s) and 
such have been hanging around for long enough, it would be good to 
actually figure out the whys and wherefores - and choose some colors for 
all the bike-sheds which don't cause anyone too much nausea!


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> The point here is that if we *were* to use back-tick then it would be worth 
> considering making it escape capable *and* interpolate capable - i.e. there 
> would be more going on. It would certainly solve one part of the balancing 
> act in terms of what people may want to use ' and " delimited strings. (I'd 
> suggest making it syntactic sugar for 'function("...")’).

Hmm… so say merge(“ string “, resolve escapes) = ` string ` ? I’ve got to say I 
wasn’t thinking of interpolation as I thought that merge does that sufficiently 
well.
> 
> However, there are other options too - at the end of the day is 
> 'format("...")' actually too onerous on occasions you want escaping?

Yes, unless you can use it in a constant or variable declaration which would be 
unusual and a bit too special casey for me:

constant kSomething = format(“this\tis\todd”)

> P.S. We should see if we can schedule some time in the next sprint to 
> actually do that analysis properly and *then* garner feedback.

Sure if you it’s a priority. The PR is only up there because I got interested 
in something on a rainy Sunday arvo. It’s not like we haven’t got other stuff 
to do and this bike shed seems to be rather large ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-14 10:38, Monte Goulding via use-livecode wrote:
Oh, please not backtick! The character is awkward to type (its one of 
the ones that moves around a lot on keyboard layouts) and difficult to 
read (and always makes me think something more is going on - e.g. as 
in bash scripts!).


Hehe, well, thoughts evolve as time goes by ;)

The point here is that if we *were* to use back-tick then it would be 
worth considering making it escape capable *and* interpolate capable - 
i.e. there would be more going on. It would certainly solve one part of 
the balancing act in terms of what people may want to use ' and " 
delimited strings. (I'd suggest making it syntactic sugar for 
'function("...")').


However, there are other options too - at the end of the day is 
'format("...")' actually too onerous on occasions you want escaping? 
Something to think about, perhaps.



Mind you we have all written a _lot_ of markdown since then so
backtick is probably much more palatable. I’m happy to change the PR
to use backtick if that’s preferred and I can either drop the single
quote thing or make it work but without escapes as an option for
strings with double quotes.


As I said in my previous email, there is more work to do here in terms 
of working out what needs to be done (as pre-requisites), and what is 
best before playing with any more code. There are too many options which 
have not been sufficiently compared and contrasted in detail - personal 
preference just isn't good enough here; we have to look carefully at 
what problems we need to solve, and work out the balance between power, 
balance and ergonomics.


Warmest Regards,

Mark.

P.S. We should see if we can schedule some time in the next sprint to 
actually do that analysis properly and *then* garner feedback.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 14 Aug 2017, at 5:45 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> P.S. There is another quote-like char which could be used for an implicitly 
> merged / escaped string literal - back-quote - `...`. So that should be 
> considered too - one option would be single-quote and double-quote delimited 
> strings are the same beyond the quote char; but back-quote delimited strings 
> do more work, i.e. de-escape and potentially interpolate. (Of course, this 
> does add *more* symbols to the language - but one thing symbols are good for 
> is readable bracketing, so maybe that's a good justification).

Haha… to quote you some 4 years ago after I suggested backtick:

> Oh, please not backtick! The character is awkward to type (its one of the 
> ones that moves around a lot on keyboard layouts) and difficult to read (and 
> always makes me think something more is going on - e.g. as in bash scripts!).

Mind you we have all written a _lot_ of markdown since then so backtick is 
probably much more palatable. I’m happy to change the PR to use backtick if 
that’s preferred and I can either drop the single quote thing or make it work 
but without escapes as an option for strings with double quotes.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-13 23:26, Monte Goulding via use-livecode wrote:

Ha “(and may not be)” should really be “(and is really really unlikely
to be)” but still it was an interesting thing to have a play with.


In its current form - yes - it is unlikely.

There are several (some orthogonal, some not) options with regards what 
we could with the way string literals can be represented in LiveCode. 
They all need to be considered in comparison as a whole in as unbiased a 
fashion as possible (when taking into account all the ramifications). 
Whilst I think most options have been mentioned we still haven't 
collected that into a more grokable form with the pros and cons of each 
which means any point of view will tend to be biased by what can be seen 
directly, rather than what could exist. (In this case this is 
particularly important for two reasons - some of the options to not meld 
together, it is one or the other and this changes the lexical structure 
of the language in a very key way).


In particular, the provision for escaping chars in a string literal is 
orthogonal to that of allowing single and double quote bounded literals 
- so the merit of both of these things need to be evaluated separately. 
Indeed, 'de-escaping' is a function which runs on a string producing the 
*actual* string and from this point of view any token structure which 
allows escaped strings is actually syntactic sugar for a function 
application (if one that is done at compile-time - but that is just a 
special-case of simple constant folding, a mechanism for which would be 
universally applicable).


[ In Monte's PR, 'X' => format("X") - abstractly at least - after the 
tokens have been converted to actual values. Since we already have a 
function which can de-escape (format), that requires some analysis 
first. Indeed, escaping / de-escaping is a simpler operation than 
'format' so perhaps they need their own functions - which would be 
useful in their own right ].


To give an idea of the balancing act, one of the key motivations for 
having single-quote delimited strings (based on the most recent request) 
is to make constructing strings with double-quote in them easier for 
JavaScript, HTML and SQL (or any language which uses double-quote for 
string literals, in fact), as well as making it easier to have literals 
for control references (e.g. 'button "foo"') but that ability is also 
weakened by *also* having escapes. e.g.


  JS: "window.alert(\"Hello\nWorld!\")" ->
 Potential LC no escapes: 'window.alert("Hello\nWorld!")' -- no 
escapes
 Potential LC with escapes: 'window.alert("Hello\\nWorld!")' -- with 
escapes


One thing which does need more thought is whether we *really* need 
escapes in single or double quoted literals at all? Is there other ways 
we could improve LiveCode Script so that they aren't really necessary 
and if not, then would it better that escaping require a little more 
than just "..." or '...' (at the moment you get the same effect as '...' 
in the PR by doing format("...") - or could, with some 
backwards-compatible changes to format(), at least).


Certainly the PR suggests there are a few other things which should be 
done first, and separately. e.g. Sorting out what identifiers can hold 
(I think we can safely remove single-quote which is a pre-requisite for 
allowing single-quote delimited literals - but is it worth cleaving out 
others, if possible?) and looking and what escaped string structure 
makes the most sense (can we define one which is copy-paste compatible 
with as many other languages as possible?).


Warmest Regards,

Mark.

P.S. There is another quote-like char which could be used for an 
implicitly merged / escaped string literal - back-quote - `...`. So that 
should be considered too - one option would be single-quote and 
double-quote delimited strings are the same beyond the quote char; but 
back-quote delimited strings do more work, i.e. de-escape and 
potentially interpolate. (Of course, this does add *more* symbols to the 
language - but one thing symbols are good for is readable bracketing, so 
maybe that's a good justification).


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 14 Aug 2017, at 6:50 am, Mark Wieder via use-livecode 
>  wrote:
> 
> I realize it's not reviewed/accepted yet (and may not be), but Monte's done 
> something impressive here:
> 
> https://github.com/livecode/livecode/pull/5781#issuecomment-322065901 
> 

Ha “(and may not be)” should really be “(and is really really unlikely to be)” 
but still it was an interesting thing to have a play with.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/12/2017 01:20 PM, Richard Gaskin via use-livecode wrote:

The q function is handy, but handier still would be to have JavaScript's 
support for interchangeable single- and double-quotes to allow nesting, 
e.g.:


   put 'Hello there, Teddy "Roughrider" Roosevelt!'



I realize it's not reviewed/accepted yet (and may not be), but Monte's 
done something impressive here:


https://github.com/livecode/livecode/pull/5781#issuecomment-322065901

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Sannyasin Brahmanathaswami via use-livecode]

Monte, you request is a bit opaque to me..

but FWIW 

-- to stay away from globals
-- to break up logical "areas of work/services" into separate scripts
-- to be able trace back to the original script  I find myself doing a lot more 
of this:


I find myself doing a lot of this;

behavior_Listen # parent of the stack "listen"
# which is serving as the controller/model for all things having to do with 
playlists etc.



on playlist_SetCurrent pList  
   put pList into sTargetPlayList
end playlist_SetCurrent

function playlist_GetCurrent
   return sCurrentPlayListA["playListTitle"]
end playlist_GetCurrent


# so then in this script:

behavior_ListenSelectPlay

# behavior attached to the card in this stack
# which is responsible for all things UI/UX related. i.e the "view manager" if 
you will

I can at anytime do a kind of "reset" with 

put playlist_GetCurrent() into tPlaylist

This architecture is all a bit new to me but turns out to be very functional 
and pretty transparent… 

so that "getter setter" thing… is that what you are looking for?

On 8/10/17, 3:50 PM, "use-livecode on behalf of Monte Goulding via 
use-livecode"  wrote:

Basically anything where you follow a common pattern to do a thing but you 
can’t abstract away so you don’t have to write the pattern any more.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/12/2017 01:20 PM, Richard Gaskin via use-livecode wrote:

The q function is handy, but handier still would be to have JavaScript's 
support for interchangeable single- and double-quotes to allow nesting, 
e.g.:


   put 'Hello there, Teddy "Roughrider" Roosevelt!'



http://quality.livecode.com/show_bug.cgi?id=16941

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Richard Gaskin via use-livecode]

Dan Friedman wrote:

> Here’s my silly contribution.   How many times do we write something
> like this:
>
> put “Are you sure you want to delete the image” && quote & myImageName
> & quote && “?” into tPrompt
>
> I have a simple q() function in all my projects:
>
> function q inData
>   return (quote & inData & quote)
> end q
>
> Now, I can simply do this:
>
> put “Are you sure you want to delete the image” && q(myImageName) &
> “?” into tPrompt
>
> Tiny, but mighty.   :)

The q function is handy, but handier still would be to have JavaScript's 
support for interchangeable single- and double-quotes to allow nesting, 
e.g.:


  put 'Hello there, Teddy "Roughrider" Roosevelt!'

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Dan Friedman via use-livecode]

Here’s my silly contribution.   How many times do we write something like this:

put “Are you sure you want to delete the image” && quote & myImageName & quote 
&& “?” into tPrompt

I have a simple q() function in all my projects:

function q inData
  return (quote & inData & quote)
end q

Now, I can simply do this:

put “Are you sure you want to delete the image” && q(myImageName) & “?” into 
tPrompt

Tiny, but mighty.   :)

-Dan
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[dunbarx via use-livecode]

The subThread about Switch/Case is a current thread on the forum:

 <http://forums.livecode.com/viewtopic.php?f=7=29586> 

Craig



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/common-code-patterns-tp4718218p4718394.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Alex Tweedly via use-livecode]

On 11/08/2017 23:17, Monte Goulding via use-livecode wrote:

On 11 Aug 2017, at 9:40 am, Alex Tweedly via use-livecode 
 wrote:

repeat with i=1 to paramcount()-1
put param(i)&"," after theValue
end repeat
put param(paramcount()) after theValue

Shorter, faster, and just plain tidier :-)

Hmm… there’s a few reasons I’m not a fan of this pattern:

- you can’t really clearly document the handler parameters although this could 
feasibly be worked around by redefining what a parameter is in your docs
Well, it's not my pattern (in fact, initially I didn't even spot that it 
did this "trick" to handle a point) - so I may be the wrong one to 
defend it - but here goes.


The common use case is where the parameters are any one of
 - one or two points
 - a rect
 - one to four coords
(i.e. anywhere you are basically passing in a rectangle in the various 
common flavours).


I think I've seen it in  few places (presumably Geometry Engine, maybe 
one of the chart libraries, etc.)


-- Alex.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 03:21 PM, Monte Goulding via use-livecode wrote:


Ha… I hadn’t considered that you might want the elements sorted instead of the 
keys but of course you might… well I’m not sure I just know I’d really like to 
have a way to iterate sorted keys and elements…
I'm not trying by any means to say that the idea isn't good. I'm also in 
favor of having a way to sort keys and elements other than the obvious. 
I just think that syntax is awkward.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Ralph DiMola via use-livecode]

I may not be obvious but neither is the sort command. When I start LC I
could not grasp "each" and what it did to what from who, but that's me. I
digress. I can't tell you how many times I've done:

Local tKeys
Put the keys of pArray into tKeys
Sort the lines of tKeys numeric
Repeat for each line tKey in tKeys
...



Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Dr. Hawkins via use-livecode
Sent: Friday, August 11, 2017 6:33 PM
To: How to use LiveCode
Cc: Dr. Hawkins
Subject: Re: common code patterns

On Fri, Aug 11, 2017 at 3:08 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/11/2017 02:59 PM, Mike Kerner via use-livecode wrote:
>
>> That is not easier to read.
>>
>
> Heh. Mike beat me to it.


. . .  After seven chalkboards of deprivation, the calculus professor
announce, "therefore, A is obviously equal to B"

A student timidly raised her hand, and said, "That's not obvious,
professor."

He scrawled three more boards, and triumphantly announced, "See, I told you
it was obvious!"

:)

--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Dr. Hawkins via use-livecode]

On Fri, Aug 11, 2017 at 3:08 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/11/2017 02:59 PM, Mike Kerner via use-livecode wrote:
>
>> That is not easier to read.
>>
>
> Heh. Mike beat me to it.


. . .  After seven chalkboards of deprivation, the calculus professor
announce, "therefore, A is obviously equal to B"

A student timidly raised her hand, and said, "That's not obvious,
professor."

He scrawled three more boards, and triumphantly announced, "See, I told you
it was obvious!"

:)

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 8:06 am, Mark Wieder via use-livecode 
>  wrote:
> 
>> I guess we could have more explicit syntax here which might be more flexible 
>> too
>> repeat for each element tElement and key tKey in tArray ordered numeric 
>> ascending
> 
> I must be channeling Mark Waddingham here... I'm worried that the syntax is 
> borderline not-xtalky. For instance, it's not obvious from looking at that 
> whether tElement or tKey is sorted numerically. By guess is that you intend 
> tKey to be sorted.

Ha… I hadn’t considered that you might want the elements sorted instead of the 
keys but of course you might… well I’m not sure I just know I’d really like to 
have a way to iterate sorted keys and elements…

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 9:40 am, Alex Tweedly via use-livecode 
>  wrote:
> 
> repeat with i=1 to paramcount()-1
>put param(i)&"," after theValue
> end repeat
> put param(paramcount()) after theValue
> 
> Shorter, faster, and just plain tidier :-)

Hmm… there’s a few reasons I’m not a fan of this pattern:

- you can’t really clearly document the handler parameters although this could 
feasibly be worked around by redefining what a parameter is in your docs
- if any of your parameters may contain whatever delimiter you are using when 
parsing the params then everything breaks if you are using comma as suggested 
above then it’s not safe to pass object references to the handler.

So my question therefore is are there many people that use this pattern and 
should we throw it around a bit to get a more robust form or is this an edge 
case of a particular developer’s scripting style?

Cheers

Monte

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 02:59 PM, Mike Kerner via use-livecode wrote:

That is not easier to read.


Heh. Mike beat me to it.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 02:46 PM, Monte Goulding via use-livecode wrote:


I guess we could have more explicit syntax here which might be more flexible too

repeat for each element tElement and key tKey in tArray ordered numeric 
ascending


I must be channeling Mark Waddingham here... I'm worried that the syntax 
is borderline not-xtalky. For instance, it's not obvious from looking at 
that whether tElement or tKey is sorted numerically. By guess is that 
you intend tKey to be sorted.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mike Kerner via use-livecode]

That is not easier to read.

On Fri, Aug 11, 2017 at 5:46 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> > On 12 Aug 2017, at 1:37 am, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > So, let me rephrase - what are the use-cases people can see for allowing
> (some variant of):
> >
> >   repeat ... with counter tCounter starting from tStart
>
> Hmm…. what about:
>
> repeat for each line tLine in line 5 to -1 of tLines with counter tCounter
> starting from 5
>
> BTW if we ever do this could the following be ordered if the array is a
> 1..N sequence… I’m not really sure if repeat for each element is ordered in
> any way currently.
>
> repeat for each element tElement in tArray with counter tCounter
>
> I guess we could have more explicit syntax here which might be more
> flexible too
>
> repeat for each element tElement and key tKey in tArray ordered numeric
> ascending
>
> Cheers
>
> Monte
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 12 Aug 2017, at 1:37 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> So, let me rephrase - what are the use-cases people can see for allowing 
> (some variant of):
> 
>   repeat ... with counter tCounter starting from tStart

Hmm…. what about:

repeat for each line tLine in line 5 to -1 of tLines with counter tCounter 
starting from 5

BTW if we ever do this could the following be ordered if the array is a 1..N 
sequence… I’m not really sure if repeat for each element is ordered in any way 
currently.

repeat for each element tElement in tArray with counter tCounter

I guess we could have more explicit syntax here which might be more flexible too

repeat for each element tElement and key tKey in tArray ordered numeric 
ascending

Cheers

Monte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 08:42 AM, Alex Tweedly via use-livecode wrote:


Is it really worth doing this by changing each of the lines ?
Is it not easier, clearer and very likely just as fast, to do:


put empty into tNewBreaks
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID & the itemDel & item 2 to -1 of tBreak  after 
tNewBreaks

end repeat
return char 1 to -1 of tNewBreaks 

With a bonus that deleting lines (i.e. not copying them) is easier.


It is indeed. Thanks.
Refactoring... er... moomin... FTW.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Malte Pfaff-Brill via use-livecode]

HI Alex,

> put param(1) into isLeft
> put param(2) into isTop
> etc.
> 
> This always has fewer lines (i.e. the same number of lines as the 
> "recombine" part), and removes the loop completely.
> 
But would change the way the functions are intended to be able to called.

myFunction(the loc of control 1) has one comma delimited Parameter
while
myFunction(item 1 of the loc of control 1,item 2 of the loc of control 1) has 2 
parameters

Thus combining all params into a literal first and then breaking out the items 
of that in the desired order

> 
> 
> repeat with i=1 to paramcount()-1
>  put param(i)&"," after theValue
> end repeat
> put param(paramcount()) after theValue
> 
> Shorter, faster, and just plain tidier :-)
> 

Agreed. :-)

Cheers,

Malte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Alex Tweedly via use-livecode]

On 11/08/2017 16:26, Mark Wieder via use-livecode wrote:


case 2:
iterating through a cr-separated list and needing to modify lines
(note: this is even more extreme if I need to delete lines):

put tBreaks into tNewBreaks
put 1 into tLine
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID into item 1 of line tLine of tNewBreaks
  add 1 to tLine
end repeat
return tNewBreaks


Is it really worth doing this by changing each of the lines ?
Is it not easier, clearer and very likely just as fast, to do:


put empty into tNewBreaks
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID & the itemDel & item 2 to -1 of tBreak  after 
tNewBreaks

end repeat
return char 1 to -1 of tNewBreaks 

With a bonus that deleting lines (i.e. not copying them) is easier.

Regards,
Alex

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-11 17:26, Mark Wieder via use-livecode wrote:

On 08/11/2017 02:24 AM, Mark Waddingham via use-livecode wrote:

Not quite on topic for the thread, but this interested in me in terms 
of - what are the use cases?


Somewhat similar to Ralph's use cases, this paradigm comes up quite
often in my code. Probably the most common case is where I want the
performance of a 'repeat for each' loop but don't have a proper
iterator to use, so I have to use a doppelganger. Examples here from
actual working code:


Hehe - I wasn't clear enough there... I meant 'use-cases for a 
generalized form allowing start index to be specified'.


Although, Ralph's suggestion of allowing a counter alongside *any* 
repeat perhaps suggests the generalization *might* be worthwhile (after 
all there isn't a thing you are counting from 1 there - unlike in repeat 
for each).


So, let me rephrase - what are the use-cases people can see for allowing 
(some variant of):


   repeat ... with counter tCounter starting from tStart

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/11/2017 02:24 AM, Mark Waddingham via use-livecode wrote:

Not quite on topic for the thread, but this interested in me in terms of 
- what are the use cases?


Somewhat similar to Ralph's use cases, this paradigm comes up quite 
often in my code. Probably the most common case is where I want the 
performance of a 'repeat for each' loop but don't have a proper iterator 
to use, so I have to use a doppelganger. Examples here from actual 
working code:


case 1:
setting up an array of constants:

put 0 into tCount
repeat for each item tConst in tConsts
  put tConst into tArray[tCount]
  add 1 to tCount
end repeat

case 2:
iterating through a cr-separated list and needing to modify lines
(note: this is even more extreme if I need to delete lines):

put tBreaks into tNewBreaks
put 1 into tLine
repeat for each line tBreak in tBreaks
  put item 1 of tBreak into tID
  put the long id of control id tID of the topstack into tObjectID
  put tObjectID into item 1 of line tLine of tNewBreaks
  add 1 to tLine
end repeat
return tNewBreaks

case 3:
parsing data and needing an iterator:

command SetVarFieldColors pFieldName
  local x

  put 1 into x
  set the itemdelimiter to tab
  repeat for each line tLine in field pFieldName
switch item 3 of tLine
  case "C"
set the forecolor of item 2 to 3 of line x of field pFieldName 
to sDebugColors["declarations"]

break
  case "P"
set the forecolor of item 2 to 3 of line x of field pFieldName 
to sDebugColors["parameters"]

break
  default
break
end switch
add 1 to x
  end repeat
end SetVarFieldColors


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Ralph DiMola via use-livecode]

Mark,

Again thanks for chiming in.
Here's an example:

Local tIndex, tDataArray
put getMyRecordSet() into tRS
put 1 into tIndex
repeat while not isEof(tRS)
 Put makeThisRecordIntoAnArray(tRS) into tDataArray[tIndex]
 Add 1 to tIndex
End repeat

Now I can sort the keys of the array to ripple thru the records.

This is what I imagined:

local tDataArray
put getMyRecordSet() into tRS
repeat while not isEof(tRS) with counter tIndex
 Put makeThisRecordIntoAnArray(tRS) into tDataArray[tIndex]
end repeat

Another example:

repeat for each word tWord in tWords with counter tIndex
 switch tIndex
  case 1
   -- first word stuff
  break
  case the number of words in tWords
  -- last word stuff
  break
  default
   -- not first or last word stuff
 end switch
 -- all stuff
end repeat

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Waddingham via use-livecode
Sent: Friday, August 11, 2017 5:25 AM
To: How to use LiveCode
Cc: Mark Waddingham
Subject: RE: common code patterns

On 2017-08-10 19:38, Ralph DiMola via use-livecode wrote:
> To make this even more flexible:
> 
> repeat for each line tLine in tLines with [counter] tIndex [start] 
> [{1}|x] [step] [{1}|y]
> 
> end repeat

Not quite on topic for the thread, but this interested in me in terms of
- what are the use cases?

The common code pattern we see as justification for 'repeat for each line
tLine and index tIndex in tLines' is that it allows you to use the
efficiency of iteration over a primary container, whilst still retaining the
index of the chunk being iterated over. i.e.

   put 0 into tIndex
   repeat for each line tLine in tContainer
 add 1 to tIndex
 if tLine is not line tIndex of tContainer then
   answer "Oh dear - something is *really* wrong"
 end if
   end repeat

So an extension to the syntax with 'index' means you get both pieces of
information and a good amount of duality which justifies its existence.

In what kinds of situation do you find yourself wanting an offset index,
relative to the index of the iterated chunk?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Mark Waddingham via use-livecode]

On 2017-08-10 19:38, Ralph DiMola via use-livecode wrote:

To make this even more flexible:

repeat for each line tLine in tLines with [counter] tIndex [start] 
[{1}|x]

[step] [{1}|y]

end repeat


Not quite on topic for the thread, but this interested in me in terms of 
- what are the use cases?


The common code pattern we see as justification for 'repeat for each 
line tLine and index tIndex in tLines' is that it allows you to use the 
efficiency of iteration over a primary container, whilst still retaining 
the index of the chunk being iterated over. i.e.


  put 0 into tIndex
  repeat for each line tLine in tContainer
add 1 to tIndex
if tLine is not line tIndex of tContainer then
  answer "Oh dear - something is *really* wrong"
end if
  end repeat

So an extension to the syntax with 'index' means you get both pieces of 
information and a good amount of duality which justifies its existence.


In what kinds of situation do you find yourself wanting an offset index, 
relative to the index of the iterated chunk?


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[J. Landman Gay via use-livecode]

On 8/10/17 3:39 PM, Monte Goulding via use-livecode wrote:

Jacque the break thing is possible but not what I’m after at the moment. Could 
you open an enhancement request and I’ll try and get that done for you.


Done:
http://quality.livecode.com/show_bug.cgi?id=20258

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Thierry Douez via use-livecode]

2017-08-11 9:07 GMT+02:00 J. Landman Gay:

On 8/10/17 7:42 PM, Monte Goulding:
>


> Over on the Parent of Target thread we are discussing local var access so
>> I wonder if this is a useful common pattern:
>>
>> local s
>>
>> command set p
>> put p into s
>> end set
>>
>> function get
>> return s
>> end get
>>
>
> Yes, I use that a lot.
>
>

+1


-- 

Thierry Douez - sunny-tdz.com
sunnYrex - sunnYtext2speech - sunnYperl - sunnYmidi - sunnYmage
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[J. Landman Gay via use-livecode]

On 8/10/17 7:42 PM, Monte Goulding via use-livecode wrote:

Over on the Parent of Target thread we are discussing local var access so I 
wonder if this is a useful common pattern:

local s

command set p
put p into s
end set

function get
return s
end get


Yes, I use that a lot.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Terry Judd via use-livecode]

Even better - the mobile commands could an error rather than spitting the dummy 
when called from a non-mobile environment.  I usually add my own mobile get and 
set handlers/functions that do the environment test and then pass the necessary 
parameter to either mobileControlGet or mobileControlSet to minimize the number 
of times I need to write this sort of code.

Terry...

On 11/08/2017 2:54 pm, "use-livecode on behalf of Scott Morrow via 
use-livecode"  wrote:

What about the use of mobile-only commands… needing to always wrap them in 
something to keep the IDE from touching.

if "mobile" is in the environment then
  mobileControlSet tObject, tProp, tValue
end if  


> On Aug 10, 2017, at 6:50 PM, Monte Goulding via use-livecode 
 wrote:
> 
> 
>> On 11 Aug 2017, at 11:45 am, Mark Wieder via use-livecode 
 wrote:
>> 
>> You know, if you'd post what you're trying to do it might be more 
possible to stay on target here. For instance, I regularly have to fill an 
array with constants in an initialization routine or use a custom property 
array filled with constants. Is that any help? Or are you looking to make a 
macro processor? Or a library of common ? Or something else?
> 
> A library of common  is probably the best description at the 
moment but the use case is not reusable handlers as we have other means for 
that.
> 
> Basically anything where you follow a common pattern to do a thing but 
you can’t abstract away so you don’t have to write the pattern any more.
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 2:54 pm, Scott Morrow via use-livecode 
>  wrote:
> 
> What about the use of mobile-only commands… needing to always wrap them in 
> something to keep the IDE from touching.
> 
> if "mobile" is in the environment then
>  mobileControlSet tObject, tProp, tValue
> end if

Yes that’s quite a common bit of code in a mobile app!

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Scott Morrow via use-livecode]

What about the use of mobile-only commands… needing to always wrap them in 
something to keep the IDE from touching.

if "mobile" is in the environment then
  mobileControlSet tObject, tProp, tValue
end if  


> On Aug 10, 2017, at 6:50 PM, Monte Goulding via use-livecode 
>  wrote:
> 
> 
>> On 11 Aug 2017, at 11:45 am, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> You know, if you'd post what you're trying to do it might be more possible 
>> to stay on target here. For instance, I regularly have to fill an array with 
>> constants in an initialization routine or use a custom property array filled 
>> with constants. Is that any help? Or are you looking to make a macro 
>> processor? Or a library of common ? Or something else?
> 
> A library of common  is probably the best description at the moment 
> but the use case is not reusable handlers as we have other means for that.
> 
> Basically anything where you follow a common pattern to do a thing but you 
> can’t abstract away so you don’t have to write the pattern any more.
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 06:50 PM, Monte Goulding via use-livecode wrote:


A library of common  is probably the best description at the moment but 
the use case is not reusable handlers as we have other means for that.


Hmmm... very mysterious.
So I take it an array of constants doesn't fit the category.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:45 am, Mark Wieder via use-livecode 
>  wrote:
> 
> You know, if you'd post what you're trying to do it might be more possible to 
> stay on target here. For instance, I regularly have to fill an array with 
> constants in an initialization routine or use a custom property array filled 
> with constants. Is that any help? Or are you looking to make a macro 
> processor? Or a library of common ? Or something else?

A library of common  is probably the best description at the moment but 
the use case is not reusable handlers as we have other means for that.

Basically anything where you follow a common pattern to do a thing but you 
can’t abstract away so you don’t have to write the pattern any more.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 01:39 PM, Monte Goulding via use-livecode wrote:


Sorry folks I should have been more specific and said using existing syntax.


You know, if you'd post what you're trying to do it might be more 
possible to stay on target here. For instance, I regularly have to fill 
an array with constants in an initialization routine or use a custom 
property array filled with constants. Is that any help? Or are you 
looking to make a macro processor? Or a library of common ? Or 
something else?

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 10:53 am, Devin Asay via use-livecode 
>  wrote:
> 
> I’d like to see one like this for conditional structures:
> 
> if  then
>  -- do if true
> else
>  -- do if false
> end if
> 
> I always try to use the “full” form of if-then-else. It solves lots of 
> confusion when you end up with nested if-thens. I teach my students to do it 
> this way as best practice, and I think it reinforces the idea of a completely 
> formed and terminated structure.

I agree Devin

The script editor doesn’t do macro completion on return of `if` because we have 
so many possible variations of that it is near impossible to work out what the 
user wants however I know I always want `return & indent & cursor selection & 
return & end if` when I hit return and the last non comment word of the line is 
then. 

I will occasionally use the single line for things like exit repeat if I’m 
feeling lazy but it’s likely I only do this because there’s no macro completion 
here so…

Anyway, as with the macro completion of `case` -> `break` adding `if` macro 
completion only if the last token is `then` would require some special casing 
in the current code which only looks at the first token of the statement and 
only does completion with end .

Cheers

Monte

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Devin Asay via use-livecode]

I’d like to see one like this for conditional structures:

if  then
  -- do if true
else
  -- do if false
end if

I always try to use the “full” form of if-then-else. It solves lots of 
confusion when you end up with nested if-thens. I teach my students to do it 
this way as best practice, and I think it reinforces the idea of a completely 
formed and terminated structure.


Devin

> On Aug 10, 2017, at 6:42 PM, Monte Goulding via use-livecode 
>  wrote:
> 
> Over on the Parent of Target thread we are discussing local var access so I 
> wonder if this is a useful common pattern:
> 
> local s
> 
> command set p
>   put p into s
> end set
> 
> function get
>   return s
> end get
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Learn to code with LiveCode University
https://livecode.com/store/education/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

Over on the Parent of Target thread we are discussing local var access so I 
wonder if this is a useful common pattern:

local s

command set p
   put p into s
end set

function get
   return s
end get

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Alex Tweedly via use-livecode]

Sticking with that style, why not do

repeat with i=1 to paramcount()-1
put param(i)&"," after theValue
end repeat
put param(paramcount()) after theValue

Shorter, faster, and just plain tidier :-)


or, to change style, is there a reason not to do

put param(1) into isLeft
put param(2) into isTop
etc.

This always has fewer lines (i.e. the same number of lines as the 
"recombine" part), and removes the loop completely.


-- Alex.



On 10/08/2017 21:18, Malte Pfaff-Brill via use-livecode wrote:

Hi Monte,

What I do way too often is combining all parameters of a function in a string 
and then split them up again as needed e.g.:


repeat with i=1 to paramcount()
if i

Re: common code patterns

[Dr. Hawkins via use-livecode]

On Thu, Aug 10, 2017 at 11:12 AM, Jerry Jensen via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Switch constructs without breaks are almost like having a 21st century
> “goto”. You can really make a mess if you try.


While doing the code for my dissertation,  I actually found that I was
duplicating a good-sized block of code that could be resolved with a GOTO.

I forget the details, but I effectively had multiple entry and exit points
in a recursive problem, and using a GOTO did  something like passing the
alternate entry setup and going straight to the shared  code--but I
couldn't simply do an IF/ELSEIF block due to the entry.

Then again, that was the first GOTO I'd used since MBASIC 5 eliminated the
need to stash setup codes in high line numbers and then return for
performance reasons--so the first time in 20 years or so.

And it was still the (very) late 20th century.

Anyway, I'll remind those who worry about such things that the failure to
provide ENDIF to IF in livecode is inconsistent with the other control
structures.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Richard Gaskin via use-livecode]

Monte Goulding wrote:


On 11 Aug 2017, at 7:02 am, Richard Gaskin via use-livecode  wrote:

Except that's wrong. :)

I tend to use 0 as the initial value, and increment at the top of the loop:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 add 1 to tIndex
 — code
 end repeat

I've found two benefits from this habit:

1. (minor) Clearer distinction between unincremented and incremented counter.

2. (major) I can "next repeat" at any point in the block and know that the 
counter is appropriately updated.

Indeed, it was a runaway loop many years ago that set me know this path.


Aha… well it probably depends on what you are using tIndex for but yes your 
pattern is much more reliable if tIndex is meant to represent the line number. 
If on the other hand tIndex is meant to only be incremented if you haven’t 
exited the loop at some point while processing tLine then you may want the 
other pattern so perhaps both have value as examples but I’m not sure how one 
would name the two different patterns. I guess you could do this which is 
probably best:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 — code for ensuring tIndex should be incremented
 add 1 to tIndex
 — code for using tIndex
 end repeat


Exactly.  Many possible waya to write code.  No single template will 
capture all needs.


Most of my loops never use counters, or I use the built-in counter form. 
"repeat with...".


So many different ways to do things.  That's why we use a scripting 
language rather than a point-and-click tool. for the flexible 
expressiveness.




Sparse minimums are fine. I just need a few examples for the moment. 


Let's start with just two:

  repeat with i =  to 
 --
  end repeat


  repeat for each  in 
--
  end repeat


Leave any specific extras for the scripter.  We need to be in control o 
those things, and many times we don't use them at all.  These barebones 
are all we need.  If we need another line we'll write it.



PS: A nagging thought just occurred to me: if the counter variable is 
named in the script, it would need to account for nested loops.


And FWIW I only sometimes use K's "i", "j", "k" pattern.  Sometimes 
I'll use more descriptive names, esp. if the block inside the loop is long.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 7:15 am, Mike Kerner via use-livecode 
>  wrote:
> 
> So back to my original question, and my original comment - you're talking
> about macros?  See my first reply.

However they are used the patterns will be the same ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 7:02 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Except that's wrong. :)
> 
> I tend to use 0 as the initial value, and increment at the top of the loop:
> 
>  local tIndex
>  put 0 into tIndex
>  repeat for each line tLine in tLines
>  add 1 to tIndex
>  — code
>  end repeat
> 
> I've found two benefits from this habit:
> 
> 1. (minor) Clearer distinction between unincremented and incremented counter.
> 
> 2. (major) I can "next repeat" at any point in the block and know that the 
> counter is appropriately updated.
> 
> Indeed, it was a runaway loop many years ago that set me know this path.

Aha… well it probably depends on what you are using tIndex for but yes your 
pattern is much more reliable if tIndex is meant to represent the line number. 
If on the other hand tIndex is meant to only be incremented if you haven’t 
exited the loop at some point while processing tLine then you may want the 
other pattern so perhaps both have value as examples but I’m not sure how one 
would name the two different patterns. I guess you could do this which is 
probably best:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 — code for ensuring tIndex should be incremented
 add 1 to tIndex
 — code for using tIndex
 end repeat
> 
> 
> 
> All this raises a bigger question:  can we for now provide some sparse 
> minimums and perhaps consider adding more later if truly needed?
> 
> Saves work for you folks, and obviates the need to have what would likely be 
> really long threads here about different coding styles (or whether all 
> possible styles should be supported in Prefs  - "Damnation to the dangling 
> 'thens'!" ).

Sparse minimums are fine. I just need a few examples for the moment. Down the 
track once you all see _why_ I’m asking then we can expand on things a bit ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mike Kerner via use-livecode]

So back to my original question, and my original comment - you're talking
about macros?  See my first reply.

On Thu, Aug 10, 2017 at 5:02 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Monte Goulding wrote:
> > Sorry folks I should have been more specific and said using existing
> > syntax. So the original thing posted is what I’m after at the moment:
> >
> > local tIndex
> > put 1 into tIndex
> > repeat for each line tLine in tLines
> >— code
> >add 1 to tIndex
> > end repeat
>
> Except that's wrong. :)
>
> I tend to use 0 as the initial value, and increment at the top of the loop:
>
>   local tIndex
>   put 0 into tIndex
>   repeat for each line tLine in tLines
>   add 1 to tIndex
>   — code
>   end repeat
>
> I've found two benefits from this habit:
>
> 1. (minor) Clearer distinction between unincremented and incremented
> counter.
>
> 2. (major) I can "next repeat" at any point in the block and know that the
> counter is appropriately updated.
>
> Indeed, it was a runaway loop many years ago that set me know this path.
>
>
> All this raises a bigger question:  can we for now provide some sparse
> minimums and perhaps consider adding more later if truly needed?
>
> Saves work for you folks, and obviates the need to have what would likely
> be really long threads here about different coding styles (or whether all
> possible styles should be supported in Prefs  - "Damnation to the dangling
> 'thens'!" ).
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Richard Gaskin via use-livecode]

Monte Goulding wrote:
> Sorry folks I should have been more specific and said using existing
> syntax. So the original thing posted is what I’m after at the moment:
>
> local tIndex
> put 1 into tIndex
> repeat for each line tLine in tLines
>— code
>add 1 to tIndex
> end repeat

Except that's wrong. :)

I tend to use 0 as the initial value, and increment at the top of the loop:

  local tIndex
  put 0 into tIndex
  repeat for each line tLine in tLines
  add 1 to tIndex
  — code
  end repeat

I've found two benefits from this habit:

1. (minor) Clearer distinction between unincremented and incremented 
counter.


2. (major) I can "next repeat" at any point in the block and know that 
the counter is appropriately updated.


Indeed, it was a runaway loop many years ago that set me know this path.


All this raises a bigger question:  can we for now provide some sparse 
minimums and perhaps consider adding more later if truly needed?


Saves work for you folks, and obviates the need to have what would 
likely be really long threads here about different coding styles (or 
whether all possible styles should be supported in Prefs  - "Damnation 
to the dangling 'thens'!" ).


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 6:20 am, Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/10/2017 10:38 AM, Ralph DiMola via use-livecode wrote:
>> To make this even more flexible:
>> repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
>> [step] [{1}|y]
>>  end repeat
> 
> I would change the syntax slightly:
> 
> repeat for each line tLine in tLines [using tIndex [start [to end]]]
> end repeat
> 
> but otherwise +1: I end up writing loops like this a lot.

Sorry folks I should have been more specific and said using existing syntax. So 
the original thing posted is what I’m after at the moment:

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
   — code
   add 1 to tIndex
end repeat

Jacque the break thing is possible but not what I’m after at the moment. Could 
you open an enhancement request and I’ll try and get that done for you.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 10:38 AM, Ralph DiMola via use-livecode wrote:

To make this even more flexible:

repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
[step] [{1}|y]
  
end repeat


I would change the syntax slightly:

repeat for each line tLine in tLines [using tIndex [start [to end]]]
end repeat

but otherwise +1: I end up writing loops like this a lot.

--
 Mark Wieder
 ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Malte Pfaff-Brill via use-livecode]

Hi Monte,

What I do way too often is combining all parameters of a function in a string 
and then split them up again as needed e.g.:


repeat with i=1 to paramcount()
if i

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 10:56 AM, Ralph DiMola via use-livecode wrote:

Using a break in every case is 95%+ of my switch usage. Also the editor
should not do this if there is a case in the immediately preceding
non-blank/non-comment line. Doing this and J's suggestion would save me lots
of typing.


Agreed. While I rely on the fall-through approach sometimes, it's much 
more often that I want break statements. And if I forget to put them in, 
it's hard to figure out where the code is breaking.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mike Kerner via use-livecode]

ick on ralph, and how about if we just get rid of case/switch, and tell
everyone to use if/else if/else/end if

On Thu, Aug 10, 2017 at 2:28 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> FWIW I'm with Jacque on this one.  Not only are exclusive blocks far more
> common in practice, they're also explicit - you can see the work "BREAK"
> right at the end of the case block.
>
> If a template doesn't include that explicit guidance, I fear for the
> experience of new users confused by how their code flows (not to mention
> old-timers who either forget to add "BREAK" or wonder why it isn't put
> there with the rest of the supplied code).
>
> --
>  Richard Gaskin
>  Fourth World Systems
>
> J. Landman Gay wrote:
>
>> On the other hand, it would prevent the common (mostly newbie?) mistake
>> where you forget to break and the switch statements run amok. I reported a
>> bug back in the MetaCard days and was gently reminded that I was an idio...
>> um... in error.
>>
>> --
>> Jacqueline Landman Gay | jacque at hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>>
>>
>>
>> On August 10, 2017 12:39:44 PM Bob Sneidar via use-livecode > at lists.runrev.com> wrote:
>>
>> Ooooh... Ah, but then someone will complain about occassionally having to
>>> delete the break.
>>>
>>> Bob S
>>>
>>>
>>> On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode
  wrote:

 How about every time I write a "case" statement inside a switch
 construct, the editor adds a blank line and then "break"?

>>>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Richard Gaskin via use-livecode]

FWIW I'm with Jacque on this one.  Not only are exclusive blocks far 
more common in practice, they're also explicit - you can see the work 
"BREAK" right at the end of the case block.


If a template doesn't include that explicit guidance, I fear for the 
experience of new users confused by how their code flows (not to mention 
old-timers who either forget to add "BREAK" or wonder why it isn't put 
there with the rest of the supplied code).


--
 Richard Gaskin
 Fourth World Systems

J. Landman Gay wrote:
On the other hand, it would prevent the common (mostly newbie?) mistake 
where you forget to break and the switch statements run amok. I reported a 
bug back in the MetaCard days and was gently reminded that I was an idio... 
um... in error.


--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 10, 2017 12:39:44 PM Bob Sneidar via use-livecode 
 wrote:


Ooooh... Ah, but then someone will complain about occassionally having to 
delete the break.


Bob S


On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode 
 wrote:


How about every time I write a "case" statement inside a switch construct, 
the editor adds a blank line and then "break"?



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Jerry Jensen via use-livecode]

Switch constructs without breaks are almost like having a 21st century “goto”. 
You can really make a mess if you try.

> On Aug 10, 2017, at 10:57 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
> On the other hand, it would prevent the common (mostly newbie?) mistake where 
> you forget to break and the switch statements run amok. I reported a bug back 
> in the MetaCard days and was gently reminded that I was an idio... um... in 
> error.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Ralph DiMola via use-livecode]

Using a break in every case is 95%+ of my switch usage. Also the editor
should not do this if there is a case in the immediately preceding
non-blank/non-comment line. Doing this and J's suggestion would save me lots
of typing.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Bob Sneidar via use-livecode
Sent: Thursday, August 10, 2017 1:38 PM
To: How to use LiveCode
Cc: Bob Sneidar
Subject: Re: common code patterns

Ooooh... Ah, but then someone will complain about occassionally having to
delete the break. 

Bob S


> On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode
<use-livecode@lists.runrev.com> wrote:
> 
> How about every time I write a "case" statement inside a switch construct,
the editor adds a blank line and then "break"?
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[J. Landman Gay via use-livecode]

On the other hand, it would prevent the common (mostly newbie?) mistake 
where you forget to break and the switch statements run amok. I reported a 
bug back in the MetaCard days and was gently reminded that I was an idio... 
um... in error.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 10, 2017 12:39:44 PM Bob Sneidar via use-livecode 
 wrote:


Ooooh... Ah, but then someone will complain about occassionally having to 
delete the break.


Bob S


On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode 
 wrote:


How about every time I write a "case" statement inside a switch construct, 
the editor adds a blank line and then "break"?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Devin Asay via use-livecode]

On Aug 10, 2017, at 11:30 AM, J. Landman Gay via use-livecode 
> wrote:

How about every time I write a "case" statement inside a switch construct, the 
editor adds a blank line and then "break”?



+2! Yes please.

Devin

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Ralph DiMola via use-livecode]

+1

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
J. Landman Gay via use-livecode
Sent: Thursday, August 10, 2017 1:30 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: common code patterns

How about every time I write a "case" statement inside a switch construct, the 
editor adds a blank line and then "break"?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 10, 2017 5:03:25 AM Monte Goulding via use-livecode 
<use-livecode@lists.runrev.com> wrote:

> Hi Folks
>
> I’m looking for a few common code patterns that you find yourselves 
> writing often but aren’t well suited to reusable handlers. So snippets 
> of code or common ways that events are handled together in a script for a 
> certain task.
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Ralph DiMola via use-livecode]

To make this even more flexible:

repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
[step] [{1}|y]
 
end repeat

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Devin Asay via use-livecode
Sent: Thursday, August 10, 2017 12:33 PM
To: How to use LiveCode
Cc: Devin Asay
Subject: Re: common code patterns


On Aug 10, 2017, at 10:25 AM, Ralph DiMola via use-livecode
<use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote:

Monte,

I find that I do this quite often

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
add 1 to tIndex
end repeat

What would be very help full is the construct:

repeat for each line tLine in tLines index tIndex end repeat

This eliminates 3 lines.


+1. I like this idea because I end of doing something similar a lot. Maybe
this sounds a little more x-codish:

repeat for each line tLine in tLines with [counter] tIndex end repeat

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Bob Sneidar via use-livecode]

Ooooh... Ah, but then someone will complain about occassionally having to 
delete the break. 

Bob S


> On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode 
>  wrote:
> 
> How about every time I write a "case" statement inside a switch construct, 
> the editor adds a blank line and then "break"?
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[J. Landman Gay via use-livecode]

How about every time I write a "case" statement inside a switch construct, 
the editor adds a blank line and then "break"?


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 10, 2017 5:03:25 AM Monte Goulding via use-livecode 
<use-livecode@lists.runrev.com> wrote:



Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.


Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Devin Asay via use-livecode]

On Aug 10, 2017, at 10:25 AM, Ralph DiMola via use-livecode 
> wrote:

Monte,

I find that I do this quite often

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
add 1 to tIndex
end repeat

What would be very help full is the construct:

repeat for each line tLine in tLines index tIndex
end repeat

This eliminates 3 lines.


+1. I like this idea because I end of doing something similar a lot. Maybe this 
sounds a little more x-codish:

repeat for each line tLine in tLines with [counter] tIndex
end repeat

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: common code patterns

[Ralph DiMola via use-livecode]

Monte,

I find that I do this quite often

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
 add 1 to tIndex
end repeat

What would be very help full is the construct:

repeat for each line tLine in tLines index tIndex
end repeat

This eliminates 3 lines.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Monte Goulding via use-livecode
Sent: Thursday, August 10, 2017 6:01 AM
To: How to use LiveCode
Cc: Monte Goulding
Subject: common code patterns

Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Paul Dupuis via use-livecode]

On 8/10/2017 6:01 AM, Monte Goulding via use-livecode wrote:
> Hi Folks
>
> I’m looking for a few common code patterns that you find yourselves writing 
> often but aren’t well suited to reusable handlers. So snippets of code or 
> common ways that events are handled together in a script for a certain task.
>
> Cheers
>
> Monte

I am not sure I get exactly what you are looking for, but I find myself
rewriting very similar code over and over again in resizeStack and
resizeControl handlers

on resizeStack x,y
...
-- what I want to do is modify part of an object rect, something like:
-- set rect of btn X to rect of btn X but with new right of y-10
-- and end up writing
set rect of btn X to (item 1 of rect of btn X,item 2 of rect of btn X,
y-10, item 4 of rect of btn X)
...
end resizeStack

Sometimes I just want to add to 1 or more items in the rect, sometime
replace the values. Using top,left,etc, MOVES the object. You have to
use the rect to resize. Of course, I could write functions (and have) to
do this. There are a lot of approaches people take with function, from
general to specific.

set rect of btn X to resizeRectRight(btn X,y-10)

A clean way to do this would be nice. Say something like instead of:
set the right of btn X to y-10 -- moves button
modify the right of btn X to y-10 -- resizes button




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: common code patterns

[Mike Kerner via use-livecode]

Do I sense macros?

I have several things that I frequently end up typing that aren't vanilla:

for any structure - repeat/if/case/etc., I normally want the "end" to have
a comment matching the beginning

if i=2 then
   something
end if #i=2

I also frequently use code blocks that I want to label
#
#


There are lots of times where you need to store a property, change it, then
restore it
For just straight code that repeats
put the itemDelimiter into theItemDelimiter
set the itemDelimiter to tab

and then below
set the itemDelimiter to theItemDelimiter


Now with 9, especially, being able to have a command set the result, there
is a lot of
if the result is not empty then exit mouseUp
put it into goop


On Thu, Aug 10, 2017 at 6:01 AM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Folks
>
> I’m looking for a few common code patterns that you find yourselves
> writing often but aren’t well suited to reusable handlers. So snippets of
> code or common ways that events are handled together in a script for a
> certain task.
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

common code patterns

[Monte Goulding via use-livecode]

Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode