Unicode is not "everywhere"...

[Curry Kenworthy]

This post regards the future of "the detailed files". I'm resurrecting 
this thread to reply to a couple of very important statements after 
helping to create a fairly fast, cross-platform tentative workaround 
(still in testing, and I only mention this since the code was already 
posted) for the currently broken or inadequate feature.

Mark:

 > My general feeling here is that 'the detailed files' and
 > 'the detailed folders' should be put out to pasture as they
 > are grossly inefficient and difficult to work with.

That could be seen to imply these logic and assumptions:

A. Our product forced users to use an inefficient method,
B. They always used an inefficient method, and the format sucks,
C. Therefore round-file it.

Here's the problem with that feeling: A is incomplete, and B is 
presumptuous - it's an assumption following from A rather than being a 
separate observation. These contradict observed reality in a good 
portion of actual user activities with the feature in question.

The tool - detailed files - is inefficient for working with a SINGLE 
file. Yes that sucks, and there are lots of lousy code examples using it 
that way out of necessity (although some are pretty slick) but it 
DOESN'T mean people haven't also frequently used it for working with 
multiple files; indeed they have! I've seen it often.

So it's still relevant, and still efficient for what it does best - an 
entire file list when the user desires something specifically 
cross-platform, uniform, and fairly fast. Users are not going to be more 
efficient making a hundred separate details calls from script. And 
cross-platform with the same code is a good thing. If we want shell we 
can use it - this is different.

Not difficult to use, either - although bonus points for pretty-print 
option(s). Just bonus points though, and just options (don't worry RG, 
nobody's sapping engine/ering time*) that's still efficient enough to 
accomplish easily by script, and people don't always use this for 
display - often for data. And not always using that data with the same 
methods or for the same purpose. Sometimes the existing format is VERY 
efficient for certain tasks.

Back to Unicode:

 > For the same reason that urlEncode and urlDecode cannot be
 > changed, the detailed files/folders cannot be changed.

Nope.

Unicode? Absolutely! This is an intentionally cross-platform listing in 
a unique format, so predating certain industry standards isn't going to 
matter much.

What people will usually need, therefore most efficient, is the Unicode 
file names included in details. And - eureka! - that would match what we 
already have with the Unicode file names included in "the files" 
wouldn't it? Quite desirable, since this is a switch adjective/param - 
"the [detailed] files".

If you need a backward-compatible URL-encoded version either by default, 
or by param/setting, that's fine and good; do what you gotta do. But 
most people most of the time are going to need the Unicode, so 
appropriate emphasis should be on what is useful. I predict not many 
people will be using the URLs in newly-written code if the Unicode 
option is there.

*And (again) this shouldn't take a ton of engineering time. If 
necessary, LC Ltc can feel free to (more efficiently) utilize something 
along the lines of our workaround as a very quick engine fix. All the 
elements you need are already there in your hand with existing features. 
No need to re-do from scratch. Just choose the most efficient route 
putting them together in the official function.

BTW, I noticed this while working with files(): ideally it would be good 
to make "the [detailed] files of tFolder" valid syntax, to mirror the 
function/param form. Despite technological gains in some areas, the 
"English-like" syntax has been neglected some in the last decade. The 
Hypertalk/xTalk syntax was underappreciated but incredibly effective 
genius, and moving away from it (even very gradually) could be 
inflicting damage on oneself.

As would, more importantly, chopping off various body parts - er, 
features - without thinking it over twice! Put down the knife a minute, 
mate, you might decide later you need that appendage. LOL. I see, and 
write, a lot of code with different users. My friendly and positive 
advice: Never underestimate the continuing appeal and value of many 
parts of the original xTalk syntax and features, nor the ingenuity of 
users in utilizing the ever-growing toolset, which is used in more ways 
and better ways (both old and new) than you or I might assume! :)

 > new functions 'fileInfo' and 'folderInfo' [...]

Yep!

For single files, we/you need only access single files.

By enumerating the attributes of these functions, you might approximate 
some backward compatibility with the format from detailed files if 
desired. People do have enough existing code based on handling lines of 
the detailed files to make this a thoughtful and worthwhile consideration.

 > [...] could replace them. [detailed files/folders]

Only if you want to substitute one inefficiency (for a certain case) 
with another (for another case). I would prefer efficiency for ALL 
cases, net efficiency, but shucks - that's just me. ;)

Great job on the 9.5 memory leak bug-swats and partial speed 
improvements! There are still leak(s), and still slow areas, but it's 
getting better. If the net bugs finally can be gotten under control one 
of these days, LC 9 will be a mighty force to reckon with! Really loving 
the new features too.

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/