Strictly speaking (was: coercing a list)
Strictly speaking (was: coercing a list)
- Subject: Strictly speaking (was: coercing a list)
- From: Richard Morton <email@hidden>
- Date: Fri, 31 Aug 2001 14:14:31 +1000
Ric Phillips' message of 31/8/01 10:29 AM contained:
>
>> error "setTID parameter of TID must be a string"
>
>
>
> Didn't it used to have to be a list of strings? (well, I mean, a list of
>
> string)
>
>
>
...I guess my
>
tendency is to simplicity, and readability. I also wanted the script object
>
I posted to make my code more readable (hence 'with' over 'given') and
>
intuitive (hence forcing a string). I always optimise my code for
>
maintainability-at-a-later-date over execution efficiency. It's a matter of
>
philosophical preference, and my approach certainly discards some of the
>
functionality of TIDs by accepting only strings, but in 99.9% of cases, a
>
single character string is what I intend a TID to be.
Very good points IMO. When I was testing my handlers, I found that tids
will take just about anything other than ASCII 0 (which crashes Script
Editor here) as a value, so I decided not to limit it.
In contemplating your script object though, I realised that limiting it
to strings could be said to be a very good thing from a
debugging/maintenance POV. I've never found a reason to set them to
anything other than a string, or a single item list containing a string
at least, and they are *text* item delimiters after all.
One of the most frustrating things for me in debugging is getting an
error far from the actual cause. There's a lot to be said for crashing
early, as opposed to limping on with bad data or whatever and crashing
later. Being strict about input data types is a really good way to
facilitate this.
I used to write handlers that were as flexible as possible, but I found
that this can lead to apparently inexplicable behaviour. It's often way
too easy (for me at least) to end up with incorrect assumptions on top of
incorrect assumptions and before I know it, my script is doing
'impossible' things that are equally 'impossible' to track down. I've
torn all my hair out already. I had to find a better way.
>
As for anyone unfamiliar with or learning about Text Item Delimiters - even
>
if you use the code I posted...
Out of interest, do you load a copy of your tid object into each handler
that needs it? If not, do you ever get false resets when it is in use by
more than one routine at a time? That's one of the reasons I didn't
persevere with my idea, but I'm not convinced that my reasoning was
correct.
I'll post a script I use for displaying the literal tids value
separately, for anyone who may be interested.
Cheers,
Richard Morton
-- Great Lies of the Music Business: "This is one of Jimi's old Strats"