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/
_______________________________________________
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
