{ 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 ~ 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
