RE: Obfuscations and little white lies
RE: Obfuscations and little white lies
- Subject: RE: Obfuscations and little white lies
- From: Scott Babcock <email@hidden>
- Date: Fri, 18 Jan 2008 09:43:39 -0800
- Acceptlanguage: en-US
- Thread-topic: Obfuscations and little white lies
You seem to take this issue rather personally. The point I'm trying to make is that the user should be allowed to choose whether to have these issues hidden from them or brought to their attention.
For gigantic suites of scripts, it's perfectly appropriate to allow the language to ease the transition to newer versions by performing a bit of hand-waving here and there.
However, I publish a limited number of AppleScript libraries. I prefer that the code in these libraries be written in such a way that I'm not relying on someone else's backward-compatibility assumptions which may or may not match my intent.
This is why I think AppleScript should have settings that control this sort of behavior. This would range from "I don't care... just make it work" to "If it's ambiguous, throw an error". Many other languages provide exactly this sort of configurability.
-----Original Message-----
Date: Thu, 17 Jan 2008 16:38:42 -0800
From: "Stockly, Ed" <email@hidden>
Subject: Re: Obfuscations and little white lies
To: <email@hidden>
Message-ID: <C3B53512.E01Cíemail@hidden>
Content-Type: text/plain; charset="US-ASCII"
>>> I understand the challenges of backward compatibility. There are
>>> myriad
tradeoffs and compromises, and it's extremely difficult (sometimes impossible) to retain 100% compatibility when altering an existing language in such fundamental ways.
That's specifically what the issue is...
>>>>I would rather have my code fail than to have issues hidden from me.
I would rather not have my code fail. I would rather not have scripts going back two, three, four or five years fail. I would rather not have scripts deployed on hundreds of macs around the office fail. I would rather not have my scripts, in the hands of innocent users, from whom everything is hidden fail. Even if that means AppleScript hiding something from me, or letting some ambiguity and equivalency creep in.
>>> Perhaps AppleScript could provide some mechanism for turning off
>>> these sorts
of compatibility tweaks.
Again, there's a cost/benefit consideration to make. Do we really need another layer of complexity to resolve a rather minor issue.
>>> In my sample code, my intent was to determine the exact data type.
>>> The
question was, "Is this object a 'string'?" I didn't intend to ask, "Is this object functionally equivalent to a 'string'?" In many cases, the distinction is immaterial, but I'd prefer to have the ability to make that judgment for myself.
Actually, in the example you provided, your script failed when it could not make string functionally equivalent to another class.
text is in {string, unicode text}
But, if you really want to determine the exact data type, and distinguish between string and text classes, you could very easily determine if an object is a string or text in tiger with a script that works in leopard.
If {class of myObject} is {string} then
-- do whatever
Else if {class of myObject} is {text} then
-- do something else
Else if {class of myObject} is {unicode text} then --do other things End if
ES
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden