Case sensitivity in Livecode ??

[Alex Tweedly]

{ Aside: any discussion where both Mark Weider and Mark Waddingham take 
part is all the better because of that; two very knowledgeable people 
with two very different viewpoints (in some areas) is a good thing. BUT 
it makes it hard to refer to what each of them said - "MarkW" is still 
ambiguous. So I'm adopting the "English public school" solution - refer 
to everyone by their surname. ]

On 07/06/2022 18:55, Mark Waddingham via use-livecode wrote:
> On 2022-06-07 17:16, Mark Wieder via use-livecode wrote:
>> 1. Because it's a function, not a constant.
> function myRestLibraryGetRootUrl
>     return "http://example.com/aUrlThatMightChange/api/v2"
>   end myRestLibraryGetRootUrl

Here I agree with Waddingham. *IF* it's a library, then it feels right 
to have a function api.

The cases where it doesn't, to me, are those where the constants are 
intrinsic to a (widespread) part of an app or subsystem ... more below.

>> 2. Because the server already build supports the "include" keyword
>> which would neatly solve the issue, but none of the other platforms
>> do. Why?
>
I don't see that 'include' does what you expect in the context of lcserver.

 From the dictionary:

> If you place the *constant* statement in a handler, you can use the
> constant anywhere in the handler. If you place the*
> constant* statement in a script outside any handler, you can use
> the constant anywhere in the handlers of that
> script.
>
The crucial phrase is the last one - "of that script". That script seems 
to be define such that the included text file is considered to be a 
different script from the main script.

So you cannot put "constant k = 17" in an included file (outside of a 
handler) and have it take effect anywhere except within the included 
file !?! And obviously if you put it inside a handle then it can only be 
used within that handler.

i.e.

include "a.txt"
     -- where a.txt contains
     -- <?lc
     --   constant k = 17
on myhandler
    put k
end myhandler

outputs "k" not "17".

So, afaict, 'include' and 'constant' do not combine well enough to be 
useful.


And in any case I think include is just too confusing / error-prone in 
the dynamic context of the IDE.

>
>> 4. Because it gets tiresome having to explain to new developers that
>> you have to declare constants in multiple scripts even though it's the
>> same constant you already declared and the workaround is to use a
>> getter function as you described.
>
> Then tell new developers that the xTalk way to do global constants is 
> constant functions in the message path!
>
or perhaps as custom props  ?

FWIW, I'm not entirely sure whether what you (Mark) want from 'global 
constants' is quite the same as what Alex wants from 'global constants', 
and I'm not entirely sure whether what I *think* you both mean when you 
ask for 'global constants' is what you are actually thinking of when you 
ask for 'global constants'...


I'm not sure Tweedly knows properly what he wants from 'global 
constants'  :-)     Maybe what I actually want would be better called 
"stack-local constants" ?


> In that vein, what would be helpful is, instead of just going 'can we 
> have global constants', propose problems you need to solve / would 
> like to solve and use-cases you have encountered where the existing 
> xTalky feature set is not sufficient to solve it in some reasonably 
> elegant fashion without 'global constants'.*
>

"global variables" in LC have a particular meaning - they are *NOT* 
usable globally, they are only available in any script in which the 
developer has chosen to declare them.

That's a very different granularity of scope than 'available where the 
function is in the message path', and I think that higher level of 
granularity could/should/might-be-able-to-be provided for constants. As 
well as being more granular, it's also more consistent (I think) with 
'global variables'.

In my earlier email I tried to avoid the problems of dynamic re-setting 
of 'global constants' by describing them as "write-protected variables" 
or "write-once" variables - but I'm not sure if that really works.


Case :  I have a CSV or TSV file, no headers, that I read in, and 
process various ways at various times. I'd like to use (in many places 
throughout the app) snippets like

  put item kTitleColumn of tLine into myTitle
  put the text of fld "Last Name" into item kLastName of myNewLine

But I have a sneaking suspicion that at some point in the future 
additional columns will appear, or be re-arranged, or .... so I won't 
use literal constant values (NOT put item 3 of ...), however some form 
of 'global constant' seems like it should work here.

There are (of course) a million ways that could be done - but none that 
I can think of provide the simplicity of usage as above, combined with 
the safety of the 'variables' being write-protected, as well as some 
form of pan-stack constants; variables which can be used (read) in the 
scope where the developer wants (by declaring as global variables), but 
are protected from inadvertent over-writing by somehow limiting 
when/where they can be written (e.g. maybe only in preOpenStack and 
librarystack).


Kind regards,

Alex.


> Warmest Regards,
>
> Mark.
>
> * I potentially have use-cases for non-script-local constants, but I 
> don't have any for 'global variable'-like 'global constants' which 
> aren't expressible with existing xTalk notions - hence why my request 
> to 'put up or shut up' ;)
>
> ---
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode