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