Re: Tid's 'n AS
Re: Tid's 'n AS
- Subject: Re: Tid's 'n AS
- From: Michael Terry <email@hidden>
- Date: Wed, 13 Nov 2002 04:13:39 -0800
On 11/8/02 1:55 AM, "bill fancher" <email@hidden> wrote:
>
On Thursday, November 7, 2002, at 02:10 AM, Michael Terry wrote:
I agree that always setting TIDs is the easiest way to avoid problems. I
disagree that saving and restoring TIDs is worthless (or actually, I
suppose, slightly harmful) as you've been implying.
>
> On 11/5/02 1:13 PM, "bill fancher" <email@hidden> wrote:
>
>> There IS no default value for tid's. That would be the case if you
>
>> could say:
>
> An environment setting an initial value is the very definition of
>
> 'default'.
>
>
That's one usage of "default", but it fails to make the distinction
>
between a value that's used if nothing else is specified and the
>
current value of a variable or property that's always used.
>
>
E.g. the "do script" command has a default value for the optional "in"
>
parameter: "AppleScript". If you say
>
>
do script x in "JavaScript"
>
do script y
>
>
The default value is used in the second statement, but not the first.
>
OTOH, if you say
>
>
text items of x
>
>
the default value (in your sense) is always used. I was merely trying
>
to point out the difference.
And as Emmanuel said in another thread, programmers prefer your definition,
of which I'm mindful. Actually, I think programmers use your definition more
often, which is not quite the same thing. A programmer isn't confused about
what the 'default' button in OmniWeb's preferences will do if he or she
clicks it.
>
> The method or persistence of the setting doesn't make any difference.
>
>
Not in your usage of the word, which, as common as it is, conflates the
>
two cases above. But given that, how would you make the distinction?
>
I'll happily adopt whatever terminology you prefer, but the difference
>
won't vanish as a result.
As a nod to Emmanuel, I'll call it 'programmer's default' for the next
paragraph or so.
However, we don't need a different terminology because the context makes
clear what we mean by 'default' with respect to TIDs. 'Default' can be
construed in a couple ways, but I should have made my point clear
originally: Why don't you want us to use 'default' with TIDs?" That is, we
can choose not to call AS's TIDs implementation a 'default' implementation,
but that doesn't change its characteristics. It seems unlikely to me that
anyone is using TIDs improperly arising from the mistaken notion that TIDs
work as a programmer's default.
The characteristics I refer to are those that give TIDs its predictability;
particularly, that AS initializes TIDs with "" when an editing environment
is opened up, that AS initializes TIDs with "" when a script is run, and
that AS preserves the last set value of TIDs for use anywhere in the script.
>
>> On Wednesday, November 6, 2002, at 06:39 AM, Michael Sullivan wrote:
>
>>
>
>>> Another fundamental tenet of defensive programming is to assume your
>
>>> users (including programmers who use your functions) could make any
>
>>> *reasonable* assumption, even though they shouldn't, and make it work
>
>>> they way they would expect unless there is a non-trivial cost to
>
>>> doing
>
>>> so.
>
>>
>
>> Assuming some value for tid's (e.g. "") is NOT reasonable.
>
>
>
> Yes it is, otherwise most people wouldn't do it.
>
>
Most people in the U.S. didn't vote last Tuesday, so I assume you'd
>
argue that it's reasonable to shirk one's duty as a citizen and that
>
those who did vote were being unreasonable.
Of course it's reasonable to not vote. And those who did vote are not only
reasonable, but admirable.
A bit off topic, but you did ask: I believe one should vote if one feels
himself or herself to be informed on the issues and candidates. To vote in
ignorance diminishes the nation. An example of practicing what I preach:
Concerning local politics, I only voted on one local measure (Measure A, for
those following along at home from Ventura County, CA). An example of
irresponsibility: Voting a party's line when one knows nothing about the
local candidates. I'm embarrassed to admit that I did this in my first
election.
It is also reasonable to disagree with me. When I use 'reasonable' I do not
mean 'perfect' or 'best'. Obviously, I think my position is best or I
wouldn't hold it. When I say a position is reasonable, I mean either that I
can see advantages in it that outweigh its disadvantages, or that, given the
complex nature of the issue in question, I can understand why the average
person might be likely to hold that view.
>
Your also presuppose that most people "do it". No one I've heard from
>
prior to this admits to it, and no one other than you has advocated it.
>
Everyone else has claimed they always set tid's before use (and restore
>
them afterwards.)
I didn't advocate anything. I would only advocate the best technique of
which I'm aware, but the best technique usually isn't the only reasonable
one, nor is it necessarily the same for all situations.
>
> People aren't dumb.
>
>
People who assume that tid's will always be set to "" are. (Present
>
company excepted, of course.)
No one assumes that. Some people, however--for instance--assume that TIDs
will be reset to "" with such regularity that they can write scripts
productively, and they never have this assumption challenged by experience.
Or, the challenge is not sufficiently costly that they need re-examine that
assumption.
I consider the assumption of a value for TIDs to be a natural one in several
circumstances. Examples:
* Writing a short script which one doesn't believe will be called from
another script. For example, while working on another project, I needed to
get the ascii numbers of characters in a string. I wrote a script that,
given a string, puts a table of characters and ascii numbers on the
clipboard. I did this as quickly as possible. I didn't save, set, or restore
TIDs.
* Imagine a person very much like myself, whose first experience with
programming is with AppleScript. He sees that TIDs have an initial value and
he uses it occasionally. He also isn't confident that he knows everything
there is to know about AS, so he's afraid that if he changes TIDs (or other
values that the system provided for him) and doesn't replace them,
inexplicable (or confusing) behavior will occur. This notion might be
reinforced when he learns that odd characters will be inserted into his
strings when coercing them from a list. 'Well, that's something I didn't
know about TIDs; good thing I always reset them to ""!' Since the most
important thing to him is getting his immediate project done, he always puts
values like these back how he found them so that he won't be bitten by
something he didn't expect. As a side-effect, he is able to assume TIDs are
"" unless he's changed them, and he writes many useful scripts without
problems. As he gains experience, has time to think about things, and his
priorities change, perhaps his scripting habits change, also. But even if
not, he is able to be quite productive.
* As others have suggested, some may prefer the style or clarity that
occasionally "assuming" a value for TIDs provides. Of course, most people
don't have to assume, as they either wrote all the code they are relying
upon or can examine it readily.
>
>> The only "side" whose code will break is the one that uses tid's
>
>> without setting them. Doing that is a BUG in your code.
>
>
>
> Oh, really?
>
>
Sure. Give me script that uses tid's without setting them first and
>
I'll give you a script that loads yours and makes it misbehave.
Addressing your first point: You can call it a bug if you want, but the fact
is that the script would have worked as expected if you'd been more
forgiving. If your aim is not optimally robust and portable code, this will
not matter to you. (Not being the slightest bit sarcastic. For instance, in
the ascii table script I referred to above, I didn't do any error checking,
either. Robustness was not a goal.) If someone uses your code, and a TIDs
bug results, I doubt you will teach them a valuable lesson. I think they
will wonder why you changed their AS environment, and they will "fix" the
bug by editing your code.
At any rate, by your definition of bug, I've never seen a script using TIDs
that didn't have one. Give me almost any script that uses TIDs and I can
load it and make it misbehave. For one's code to be perfectly defensive, I'd
expect to see something like:
-----
try
set AppleScript's text item delimiters to ""
on error
set AppleScript to {text item delimiters:""}
end try
-----
or maybe:
-----
property as_env: AppleScript
somehandler() -- don't know what happened in here
set AppleScript to as_env
set AppleScript's text item delimiters to ""
-----
Of course, people aren't going to do this, because the costs are too high.
Accepting that some code like the above is warranted means accepting that
AppleScript's tab, return, space, and version properties are virtually
worthless, too. Instead, we rely on the probability that the AppleScript
variable and its properties will remain predictable, knowing that the risks
are small. Similarly, those who count on TIDs being reset rely on this
proposition's high probability. Most people write most of their own code,
most publicly available code restores TIDs, and most publicly available code
is editable--taken together, this means that those who choose to rely on
TIDs being restored will be productive.
>
> Why does AS give a default value to TIDs, then?
>
>
A property HAS to have SOME value (even if it's "missing value"). That
>
doesn't mean that you can assume it hasn't been changed from its
>
initial state.
Yes, but it wasn't given 'missing value'. It was given a useful value, just
like the rest of AppleScript's properties.
>
People make mistakes. That's a fact. To assume people will always
>
"restore" tid's is unreasonable, particularly when you're talking to
>
some yahoo who says he never bothers.
>
>
Using Paul Skinner's toilet seat metaphor: If you make sure the seat is
>
down before you sit you'll never fall in the toilet (even if you have
>
John Delacour over for a visit.)
At a certain percentage of consistency less than 100%, John could return the
toilet seat to its down position so habitually that women who know him would
be encouraged to sit without checking.
What I would advocate is writing code in such a way as to get the most stuff
done. At the point where that means writing your scripts in such a way as to
interoperate with others' code while producing the fewest apparent bugs, the
best strategy is to save, set, and restore TIDs.
Mike
_______________________________________________
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.