LiveCode Forums.

I'm sure if there is a reason for the current behavior:
This only works if ~/Desktop/myFolder/ already exists. If not, you have to create it. So you have to do:
Seems it would be convenient for directories to be created on the fly if they don't exist.

That sort of change would break any code that expected/depended on the existing behavior. Normally that sort of different default behavior would warrant a new function, but this isn't a function call, at least not a discrete one.

I'd propose changing "create folder" so that giving it a larger chunk of a pathname (more/than/one/folder) would create them all—if that's not what it already does. (I don't think so, but I haven't checked.) That wouldn't break existing code that uses just a single folder name as an argument, but it would make creating nested folders as simple as a single line of code.

It would not break any behavior of existing code. You could still check if directory exist before creating it or create without checking.

Marek

If someone has a function that should only write to a file its folder exists, and do nothing if the folder doesn't exist, then writing:

put it into url "file:missingFolder/filename.txt"

...would do nothing if the folder missingFolder did not exist. But if the code was changed to create folders, then that line would always write to that file, instead of failing when the folder is wrong, as expected.

I know I once wrote code like that where I knew only one of two folders existed on the client's computer, and that file X should be written to whichever one was there. I did not want it to create the other folder.

put mydata into url "file:male/mydata.conf"
put mydata into url "file:female/mydata.conf"

Would only write to only one file if only one of those folders existed.

Creating missing directories by engine should be much quicker than what we have now. If such future exist, there is possible one line command. You can always check if directory exist if you need that before save the file.
So it's better to go run around only in case if you have special, sporadic needs like your example. It's more reasonable for me.

Marek

I agree with you there, snm. It would have been better if the url and "file:" keywords would create any missing folders in the path they are given. But since they don't, changing the existing behavior would, as I described, break existing code. That should always be avoided since someone that didn't notice such a change in the release notes or forgets that, somewhere in their projects, there's some code that depends on the existing behavior, they would have no idea why their program suddenly is doing things it never did before.

The idea is good, but the timing is wrong to implement it now, particularly as it is just an ease-of-use change. Better to make another easy way to do the same thing, like expanding "create folder" to make more than one at a time. So that...
...would do the same as...
Then you could replace your proposed...
...with just two extra lines...
...instead of five extra lines...
And that change won't break existing code since calling "create folder" with more than one folder does nothing at all right now. It doesn't even create the first folder. There's nothing to break.

I propose:
Typically when expanding the syntax, we get a new modifier like that, which leaves the original behavior intact.

What Jacque said.

+1

+1. And maybe also Marek

I liked this enough to put in a feature request for it: http://quality.runrev.com/show_bug.cgi?id=11416

May I suggest modifying the syntax to use 'recursively' seeing as I recently added it as syntactic sugar for the union and intersect commands so they recurse multi-dimensional arrays...

@Monte, I agree they should be consistent, but to be honest, I'd like to see your additions changed. Except for the new array syntax there are no other adverbs in the language (oops: found one exception, below.)

flip img vertical
sort lines of var numeric
move btn 1 50,50 relative

I thought the union/intersect change was the only adverb in the language until I found this (also recently-added) one:

start using font file tPath globally

Which I also think is wrong. Could you make your array syntax accept both "recursive" and "recursively" to make it easier for us old-timers who have never before had to use adverbs?

Hmm... can you raise this on the engine forum? I think both of these adverbs were recommendations from Mark. It's a quick change but it would want to happen before 6.5 is out.

Done. You guys can hash it out.