On 2015-09-25 14:11, Roger Eller wrote:
Looking at this from a Windows-only end-users perspective, when a path
is
"shown" to them in a field, or "typed" by them into a command prompt,
the
separator they see and use is a backslash "\". So you are suggesting
that
every such path input by a user should have a replaceBackslashes
function
called before **using** the path in code to access files or folders -
even
though it works as-is.
Well, OK then.
There's always going to be contention with a cross-platform environment
and individual platform concerns. If the primary goal of LiveCode is to
be cross-platform, then the guidance we provide, syntax the engine
provides and semantics it follows have to allow you to (as much as
possible) write code once and have it work the same on all platforms.
Now, obviously, there is a problem here with someone using LiveCode to
write an application which is for (and will only ever be) for just one
platform - as it requires them to abstract some concepts in some cases
where it is not entirely clear why they should have to.
If we raise '\' to be a fully supported universal path separator, then
it means that there will be places on the non-Windows side where code
will not work. Indeed, if one thinks about the possibility of wanting to
use third-party libraries (written in LiveCode) then it means any such
libraries will either be '\' supporting, or not-'\' supporting depending
on whether they are 'aware' of potential use of '\' by the applications
which use them.
In any individual circumstance, where the developer is fully aware of
the issue, is not using anyone else's code and knows that the app is for
and only ever for Windows it doesn't matter.
However, my somewhat 'hardline' responses on this question are with the
best intentions; as a matter of general principal and guidance about how
to write software with LiveCode given the potential pitfalls with
separators it seems wise to advise that '/' should be used for path
separators, does it not?
As I said in a previous email, there is always a need to transform user
input into 'computer understandable values', and the 'computer
understandable values' into user output for display (the 'parsing' and
'formatting' problem) - however, in a language where 'most things are
strings', it is easy to forget this fact (as things tend to get turned
into strings when needed without explicit script support). In other
languages where the distinction is completely clear through typing, you
*have* to take explicit conversion action so the developer has to make
an explicit choice at each of these places which it occurs.
Given that there is a direct analog between file path display and
processing, and numeric display and processing it seems to me that an
eventual 'nice' solution to the problem should follow similar lines.
Perhaps field properties which cause the display / input to be in
user-world, but the underlying values you manipulate in computer-world;
or perhaps nice syntax which parses and displays strings:
put tFilePath formatted as filepath into field "Foo"
put tAmountInUSD formatted as currency into field "Foo"
Of course, another option would be to allow file separators which the
engine understands to be configurable through a global property - this
would certainly fix the problem for Windows-only apps but then put an
extra tax on any third-party component providers who would have to
ensure they respect this global property anywhere they processed file
paths.
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
