Re: AsciiNumber & AsciiCharacter Handlers
Re: AsciiNumber & AsciiCharacter Handlers
- Subject: Re: AsciiNumber & AsciiCharacter Handlers
- From: Arthur J Knapp <email@hidden>
- Date: Wed, 08 May 2002 19:21:41 -0400
>
Date: Wed, 8 May 2002 20:26:22 +0100
>
From: has <email@hidden>
>
Subject: Re: AsciiNumber & AsciiCharacter Handlers
>
Nigel Garvey wrote:
>
>> tell (a reference to text item delimiters)
>
>> set {o, contents} to {contents, c}
>
>> set {i, contents} to {my kStr256's text item 1's length, o}
>
> It's very inefficient code though and the above snippet takes about twice
>
> as long to execute as its conventional counterpart.
>
Another problem [no offence] is that it's almost unintelligible. Compare it
>
set oldTID to applescript's text item delimiters
>
set applescript's text item delimiters to c
>
set i to kStr256's text item 1's length
>
set applescript's text item delimiters to oldTID
>
This is much more legible [1]. Not just to novices, but also to experienced
>
scripters and even the original author.
If I am the original author of which you speak, I'm afraid I have to
disagree, though I'm willing to admit that I may be unique in this regard.
>
This topic really begs the question as to why all our programming tools
>
don't come with autocomplete and glossary [4] features as standard. Users
>
could reduce much of this tedious, repetitious typing down to a couple of
>
keystrokes if these sorts of features were standard, and tool developers
>
might make a few bucks from grateful customers in the process.
There are some interesting issues with regard to auto-completion that
have been discussed on the Script Debugger mailing list. Given that
AppleScript allows for white space in it's identifiers, as well as the
fact that containment can be expressed in 2 different ways:
i of j
j's i
means that an AppleScript autocompletion tool would have to be especially
intelligent. (In my personal experience, most auto completion tools are
NOT especially intelligent). ;-)
>
[1] Though it'd a lot better if meaningful variable names were used instead
>
of 'c', 'i' and 'kStr256'.
Again, I guess it's just me, but I find this difficult to read and
immediately comprehend:
set oldTID to applescript's text item delimiters
set applescript's text item delimiters to c
set i to kStr256's text item 1's length
set applescript's text item delimiters to oldTID
It becomes even more difficult for me to process in "Cal" format:
set oldDelimiters to text item delimiters of AppleScript
set text item delimiters of AppleScript to characterToConvert
set convertedInteger to length of text item 1 of characterSetString
set text item delimiters of AppleScript to oldDelimiters
This is an overload of close-fitting big words and whitespace-delimited
references that takes my eyes a while to "parse". I find it difficult to
read code in the same way I would read a novel. It forces me to constantly
switch from my brain's left hemisphere to it's right one. In more
traditional languages, I have an easier time writing code that I can then
later read quickly and immediately comprehend what is happening:
function ProcessCharacter( c )
{
with ( AppleScript )
{
o = text_item_delimiters ;
text_item_delimiters = c ;
i = kStr256.text_item[ 1 ].length ;
text_item_delimiters = o ;
}
return i ;
}
I use simple single-character variable names when I believe that
their usage is clear and unambiguous, (though not nessesarily to an
absolute beginner). I also tend to use the same single-character
variable names over and over again for the same types of values,
ie: c == character, i == integer, etc. Many of these conventions are
relatively "standard", in the sense that when I look at other programming
code on the Internet, many people are using the same variable names for
the same purposes in the same situations, (though in very different
languages, obviously).
The tendency of AS to be "verbose" can be a wonderful thing for a
beginning scripter, but it can also become a nightmare for someone trying
to "master" the language. While it is possible for more descriptive
terminology to increase the understanding for the "uninitiated" user, I
believe there is a cut-off point for how helpful it is to advanced users.
I tend to "rate" the AppleScript learning curve in this way:
A user's difficulty in moving from being a...
- Newbie to a Novice, (how do I open a folder?) --> A++
- Novice to Intermediate, (munge the folder's name) --> C-
- Intermediate to Mastery, (efficiently munge the name) --> D-
- Mastery to Advanced, (objects, math, data structures) --> F
You can compare this to a language like Perl, where I suspect the
curve is the exact opposite, ie: Perl is incredably difficult to
first get into, but becomes easier as you go along from one level
of mastery to the next.
OK, I've probably angered a lot of people now, so I'll just conclude
by saying, "please don't flame me".
;-)
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
<
mailto:email@hidden>
try
<
http://www.AppleScriptSourcebook.com/>
on error number -128
end try
}
_______________________________________________
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.