Re: Scripting Style (was: Re: Hiding Slaves)
Re: Scripting Style (was: Re: Hiding Slaves)
- Subject: Re: Scripting Style (was: Re: Hiding Slaves)
- From: has <email@hidden>
- Date: Sun, 15 Sep 2002 14:03:50 +0100
Paul Berkowitz wrote:
>
>> [...] it's more a matter of personal taste: some
>
>> people prefer to it it the "textbook" way 'as string'.
>
>
>
> Being a thoroughly uncharitable and unkind sort, I'd tend to attribute it
>
> not to "taste" but to faddishness, cargo cult, cleverness for its own sake,
>
> deliberate obfuscation, L33Tness, etc. [1]
>
>
Although all that is quite probably true, I think John mostly doesn't like
>
typing.
Too late! He's an AppleScript user: his future RSI is already ensured! <g>
>
> 'As string' is entirely unambiguous, dirt simple to read and understand.
>
> That empty string concatenation is not (as Ken's post has just
>
> demonstrated). It's just bad programming. [2]
>
>
It's not bad programming
Bad programming in no way precludes the possibility of code working. It
just means the route you took there was a poor one when better options were
available. Like writing a thousand line script without ever using handlers.
Or naming all your variables after characters in Lord of the Rings. (To
give blatantly OTT examples.)
>
since the ASLG gives it as a valid method. It's in
>
there - go check.
The ASLG never proposes the empty-string-concatenation approach in place of
using an explicit coercion [that I can see].
>
They happen to use longer strings than "", but it's the
>
same method.
Same method, but used for _different_reasons_. Doing:
"My age is: " & someInteger
may use the same concatenation operation as in:
"" & path to scripts folder
but somehow the meaning of the former is immediately apparent, whereas the
meaning of the latter is rather less so. While:
(alias "frank:workfolder:file1.txt") as string
also indicates its intent perfectly. So there must be more to this
programming lark than mere machine compiler mechanics. Whose benefit are
you writing this code for, after all? (Hint: it's not the machine's. They
consider anything above raw machine code a royal pain.) It's an abstract
argument, I know, but you're already living in a world of abstractions, so
roll with it. [BTW, those parentheses in the 'alias' example above; whose
benefit do you think they're for? I could have used 'alias
"frank:workfolder:file1.txt" as string', but I didn't. Why is that?]
Can you see what I'm getting at, or have I lost everyone already? <g>
>
It certainly is not as clear or easy to read when used as an
>
educative tool, as this mailing is.
This is a good point. (I probably hammer it way too hard, but better that
than not at all.;)
--
>
also - why not be more efficient, even for
>
1/10,000th of a second?
That's no kind of justification for doing one thing over the other. If the
underlying AS implementation changed so that '"" &' was 1/10,000th of a
second faster than 'as string' would that be adequate reason to swing the
other way? These things only matter in context, and, once looked at there,
often turn out to be utterly insignificant in comparison to other factors.
But efficiency and optimisation are topics for another time, so let's not
get too sidetracked here.
>
Nevertheless, Applescript gives many ways of doing
>
things, and that one is valid and works.
This is true of most any language. Heck, if you look at Perl, it absolutely
delights in providing as many different ways to do the same task as
possible, hence its slogan that "There's more than one way to do it."
(Along with the unofficial corollary: "There's more than one way to f**k it
up.") Some languages actively encourage it while others try to discourage
it, but the end of the day it's down to the coder to behave responsibly in
the midst of that anarchy and take care of them and theirs.
Now _of course_ coders are free to behave absolutely any way they choose,
just as long as it's _not_ at anyone else's expense. Even then, try to
judge things objectively first: "Am I doing this because it's the right
thing to do, or only because I want to impress the ladies?" Freedom without
responsibility is foolish and potentially dangerous.
--
>
>> property u : ("" as Unicode text)
>
>>
>
>> set hidFolderPath to ((u & (path to scripts folder)) & ".hid")
>
>
>
> First person to do this, I kill just on General Principles.
>
>
>
> You've been warned. ;)
>
>
What i do all the time is
>
>
property lf : (ASCII character 10)
>
>
>
for real, substantial efficiency improvements throughout a script, since it
>
saves hundreds or thousands of calls to a scripting addition . Are you going
>
to kill me too?
No, but you do get a Chinese Burn for trying to erect such a straw-man
argument:p. Tsk. You should know I'm all for the appropriate use of
user-defined named constants, enumerated types, etc - and this argument had
nothing to do with that.
>
Personally, I think 'lf' is clearer than 'ASCII character
>
10' as well
'LF' is much clearer than 'ASCII character 10' (a completely abstract,
meaningless concept in itself), because 'LF' tells you something about that
value. That said, however, 'linefeed' is much clearer than 'LF' (an
abbreviation that non-technical folks may not be familiar with). Remember,
audience is also a factor. Just look at the way AS itself is designed: all
that verbosity exists for more reason than to wreck poor JD's fingers;).
Creating and using your own 'linefeed' constant is no different really to
using the built-in 'return' constant. Yes, there's also a not-insignificant
saving in time to be had from doing this, but the _primary_ advantage [1]
is that you've succeeded in making your code more legibile and easier to
understand.
Which neatly brings us back round to my original argument: make your code
as clear and as self-explanatory as possible. AppleScript won't provide any
high-level semantics for you: it's up to _you_ to add meaning to your code.
Choose to code along the path of least surprises, and you're already on
your way.
Hope you enjoyed :)
has
[1] As I've said elsewhere, folk obsess way too much about "speed". I used
to be mad about it myself, yet my scripts ran slow as molasses. Now I
concentrate on making my code "well structured", and hey-presto it runs
much faster _and_ is far easier to optimise if it's not yet fast enough.
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.