I’m not saying it isn’t. Any system that’s robust and reliable is a good one. That doesn’t imply that it’s the only good one, nor even the best one. If you’re familiar with AppleScript’s history, then you’ll know how and why this particular practice came about.
Most people in this forum probably eat sugar.
I don’t imagine anyone’s aim is to end up with more errors in their code. That approach isn’t necessary in order to produce error-free code, but if you find it works well for you, that’s good and I’m not suggesting you need to change. Besides, If one has a system that’s consistent and reliable, it’s probably good to stick with that as re-habituating oneself can be a painful process. So, yes, keep doing that if it helps you.
One would hope that this would be part of it, at the very least.
Yes, ideally. That’s usually what I try to advocate and demonstrate, which is all I’m doing here.
It’s not always about something being “good” or “bad”. Every problem has more than one solution, and, for the most part, each solution will have its merits and drawbacks. There’s rarely one perfect, universal solution to anything,
@robertfern’s method for obtaining the file name from its path is a common one, not just within the AppleScript sphere. It’s a naive solution, which sounds like an insult, but it’s an actual term used to refer to a method of achieving something that, by and large, should work fine, and often represents the most intuitive approach that one arrives at first, but it won’t generally contain any optimisations, and may—as is the case here—not cover certain scenarios that may be desirable to have covered in the general case.
As you pointed out, writing code that will be error-free is an important goal, and to do this, it’s crucial to be able to identify situations in which one’s code might not be error-free. This doesn’t mean the code is unusable or bad, and, indeed, a lot of professional software will include a documented list of “known bugs”.
Even if a piece of code appears to work fine, it’s important to be able to consider, find, and identify how and when errors might or will arise (even theoretical ones). It’s not necessary to consider every single conceivable scenario, especially if they’re so obscure they’re unlikely to happen. But, at a minimum, for a piece of code that performs a minor (non-critical) function, one should be thinking about the common scenarios that might lead to failure; and for any code that the rest of a script will depend on in order to function properly, it’s obviously more essential to broaden the scope and include more edge cases that, by themselves, might not be likely, but acknowledging that, over time, even uncommon things will probably happen at some point.
As I said, @robertfern’s method of obtaining the file name from its path is a common one. In bash scripting, for example, "${filepath##*/}" essentially uses the same method, by returning everything after the last occurrence of a slash. In a shell script, it’s a perfectly reasonable method to use, as there’s only one notation that’s used consistently to represent all file paths, where a slash always delimits directory levels and a standardised file path won’t ever end with a slash, even if the path points to a folder. AppleScript is aware of two different kinds of file path. I won’t go into the situation involving colons appearing in posix paths again, as you can read about that above; however, the situation where a colon appears at the end of an HFS file path was one @robertfern hadn’t considered, because he didn’t think about what constitutes a file in AppleScript terms versus what constitutes a folder:
This isn’t true, because MacOS has a notion of something it calls a package file which, similar to folders, act as containers in which other files and folders (and package files) are stored, but are treated and presented by the system (and by AppleScript) as a seemingly-regular file. Thus, the command choose file, which doesn’t allow one to select a folder, does allow one to select package files. A standardised HFS path pointing to a package file will have a terminating colon. @robertfern’s method will therefore incorrectly returns the file name of any of the following types of file: applications, script bundles, rich text bundles, Automator workflows, and basically tons of other file types that we are used to regarding as ordinary files, but aren’t.