Re: Tid's 'n AS
Re: Tid's 'n AS
- Subject: Re: Tid's 'n AS
- From: email@hidden (Michael Sullivan)
- Date: Mon, 11 Nov 2002 14:17:55 -0500
- Organization: Society for the Incurably Pompous
bill fancher writes:
>
On Thursday, November 7, 2002, at 02:10 AM, Michael Terry wrote:
>
> On 11/5/02 1:13 PM, "bill fancher" <email@hidden> wrote:
>
>> 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.
If I always set *and* reset TIDs, your script that loads mine won't make
it break. If I ever use a function that you design and forget to set
TIDs immediately after using it, it might break my script -- even though
I had specifically set TIDs to what I wanted before I called your
function. Even though I might want to use those TIDs in the same code
line that I called your function.
If you use TIDs processing to return a list in your function foo, what
if I want to say
set text item delimiters to ""
set newdata to foo(somedata,parameter1) as string
I certainly prefer that to:
set footemp to foo(somedata,parameter1)
set text item delimiters to ""
set newdata to footemp as string
Which introduces another variable and assignment
And is the only way to make things work if your "foo" doesn't restore
TIDs.
I agree with Richard Morton that one should not modify thigns outside
the scope of the function unless there is a very good reason for doing
so (i.e. the caller of the function would/should expect this as part of
the function's job).
When I call some random function, I don't want to have to know its
implementation details to know whether I need to reset TIDs everytime I
call it. If I *did* know that, and needed to call the function more
than a couple times, why I'd want to rewrite it to put the either the
TID resetting or whatever I was going to do with the TIDs into the
handler so that I didn't have to keep writing the same extra lines of
code every time I called it.
Where does that lead? Well, to make the handler as general and portable
as possible, that means saving and restoring TIDs.
So yes, whenever I use TIDs in a handler or script object method, or a
script that I ever expect to call from elsewhere, I set and restore
TIDs.
As long as I do that my code can never break yours, and you can never
break mine from outside (only from inside if I trust one of your
scripts/handlers).
Where's the harm in that exactly? At worst it's a waste of two
instructions and little extra typing. In the case where I want to do
TIDs processing on the result of that handler, I don't lose *anything*,
and it makes my code clearer. In the case where I want to do that more
than a few times with the same handler, it's a pretty big win. Even if
I never use it, by saving/restoring TIDs, I've successfully encapsulated
the implementation details of that handler. I no longer have to worry
about side effects from calling it.
I'm having trouble believing that you don't get the value of this. Why
not just make all variables global and to heck with lexical scope? If
calling code doesn't want bindings changed, it should bloody well save
them in some temporary location before calling a function. That makes
about as much sense as your argument for not restoring TIDs.
Do I need to make sure that TIDs are correct before using them? Of
course. Personally I trap nearly all TIDs functions in handlers anyway
(which save and restore) so I'm not going to run into problems with
someone else's script unless I mess up. (same as you -- if you forget
to do what you're supposed to, your scripts will break).
The difference is that I only have to worry about the problem when I'm
in the function in question. Once I've thoroughly tested/debugged that
handler, I no longer have to worry about the implementation details --
you do. And if you *don't* then you're going to be resetting TIDs a
whole bunch of times where it's not necessary anyway.
My guess is that you are writing code that is much more procedural (and
less functional) in style than mine. I would have to do great violence
to my coding style to operate the way you are suggesting.
Just for the heck of it, I threw this little hack-a-mod together for
when you get tired of typing out "applescript's text item delimiters"
I know you won't use it, but perhaps somebody else will be interested.
script tidstack
property stack : {"", ""}
property idx : 2
end script
on pushtid(s)
set end of tidstack's stack to AppleScript's text item delimiters
set AppleScript's text item delimiters to s
set tidstack's idx to (tidstack's idx) + 1
end pushtid
on poptid()
set s to AppleScript's text item delimiters
set AppleScript's text item delimiters to item -1 of tidstack's
[NO-BREAK]stack
set tidstack's stack to items 1 thru ((tidstack's idx) - 1) of
[NO-BREAK]tidstack's stack
set tidstack's idx to (tidstack's idx) - 1
return s
end poptid
--sample client code:
pushtid("s")
pushtid("t")
set a to text items of "atatatatatat"
set s1 to poptid()
set b to a as string
set s2 to poptid()
set c to a as string
{a, b, c, s1, s2}
--> {{"a","a","a","a","a","a",""},"asasasasasas","aaaaaa","t","s"}
Of course's this isn't thread safe... If some handler forgets to pop,
you could end up popping the wrong tid off the stack. To do this
completely safely, you'd need to encapsulate the handlers in the script
object, and generate your own instance in every handler. Not sure, but
I suspect that would be an efficiency problem. anyway, it's a thought.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden
_______________________________________________
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.