Platform-specific file path delimiters

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps