Case sensitivity in Livecode ??

[Mark Waddingham]

On 2022-06-07 17:16, Mark Wieder via use-livecode wrote:
> 1. Because it's a function, not a constant.
>   put gkMyMagicValue() into tVar
> is cognitively different from
>   put gkMyMagicValue into tVar
> 
> Something like 17 is a trivial case. Something more like real world
> usage would be
> 
> constant kRootURL="http://example.com/aUrlThatMightChange/api/v2"

I see and what is kRootURL the Url for? If I were writing a library for 
a web-service and needed (for some reason) to expose the underlying URL 
to callers of the library, then I'd have simply define a function as 
part of its public API:

   function myRestLibraryGetRootUrl
     return "http://example.com/aUrlThatMightChange/api/v2"
   end myRestLibraryGetRootUrl

I don't buy the 'cognitively different' argument - different languages 
have different patterns. I really don't see that getting into the habit 
of using 'constant functions' instead of 'constant variables' is any 
different from getting into the habit of doing assignment as 'source 
into target', rather than 'target = source'; or getting your head around 
the message path.

It is definitely *not* unusual for libraries in any language to expose 
*all* that they do via functions - whilst you can use enums and 
preprocessor defines in C/C++ for global constants - they make your 
library unwrappable easily by higher-level languages. Indeed, you tend 
to find that as published low-level (C/C++) libraries have evolved they 
have changed to ensure their interfaces are entirely function based ones 
(indeed, oftentimes C++-based libraries gain a C function wrapper to 
make this easier - as C++ is a nightmare to wrap stuff from due to the 
immensely complicated semantics, these days, of C++ classes).

> 2. Because the server already build supports the "include" keyword
> which would neatly solve the issue, but none of the other platforms
> do. Why?

You can't really compare the features of the PHP (C preprocessor) style 
operation of the server engine with the object-based scripting of the 
normal LiveCode engine.

In that PHP-likeness, 'include' makes sense as the server engine is 
essentially doing a continuous 'merge' - emitting interleaved blocks of 
content (text) with content generated from code.

The include which is present there makes sense for that form of coding - 
i.e. for generating text documents from a mixture of prewritten text, 
and evaluated script. I don't think it makes sense when scripts are 
attached to objects where more structure is needed and they exist in a 
dynamic environment.

Critically, the server engine loads and parses files in a linear fashion 
- emitting the text, and executing the interleaved script. Everything is 
completely transient - when the document has finished being emitted, the 
engine terminates.

It raises too many edge-cases and questions as to what should happen in 
various different scenarios (as well as being a very large noose with 
which people could hang themselves) when you try to add its 'include' 
operation to the normal LiveCode environment.

Remember that in the server engine include operates on a file so  what 
would you expect to happen if you change the file? Does the engine have 
to track changes and recompile any object scripts including it when they 
change? (Remember that object scripts are compiled on being set, or when 
first tickled by a handler lookup if already set and loaded from disk).

> 3. Because every other language I've used has global constants and
> makes this easy. It's only xtalk that makes this hard. If an LC goal
> is to provide a tool for learning coding then multiple definitions of
> the same constant is a paradigm that is not transportable to other
> languages, and indeed will probably result in a compiler error.

xTalk does not make it hard - see above - its just different because of 
its model.

Of the languages you've used how many are object-based, where objects 
have scripts which can be dynamically (re-)attached continuously 
throughout the lifetime of a programs execution and, moreover, can be 
dynamically created at runtime; and more specifically, where a script is 
a defined set of handlers and other definitions which are completely 
independent (from the point of view of compiling) of any other script?

For those which you have found which fit that pattern, do any of them 
have global constants?

> 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!

Saying that is a workaround is akin to telling them that:

   "The workaround for not being able use the syntax 'X := Y' is to use 
the syntax 'put X into Y'"

Or telling someone learning Java that:

   "The workaround for defining a global function is to make it a static 
method of some class"

The point being that how you do things in different languages is 
different...

xTalks don't have a concept of 'global constant' because the language 
and runtime model isn't one which really supports such a thing (as it 
stands) - however if you need a constant available globally then 
leverage a function in the message path to do so.

Java doesn't have the concept of a 'global function' because it is a 
pure class-based language - however if you do need a global function, 
then you can just make a static method in a class.

Neither of these things are 'workarounds' - they are how you do things 
in that language!

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'...

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'.*

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