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: Thu, 17 Jan 2008 12:48:05 -0800
- Acceptlanguage: en-US
- Thread-topic: Obfuscations and little white lies
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. These are problematic issues, and I agree that the AppleScript engineers have done a fabulous job in balancing backward compatibility with enhanced functionality.
For my purposes, I would rather have my code fail than to have issues hidden from me. Let me know when ambiguity and equivalency may be causing my code to be interpreted in a way that I did not intend. Perhaps AppleScript could provide some mechanism for turning off these sorts of compatibility tweaks. This is akin to the warning levels provided by other languages.
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. Perhaps a 'like' operator could be provided to express this sort of functional equivalency evaluation. Of course, this wouldn't be backward-compatible...
-----Original Message-----
Date: Wed, 16 Jan 2008 21:05:47 -0800
From: Ed Stockly <email@hidden>
Subject: Re: Obfuscations and little white lies
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset="us-ascii"
> I have to echo previous posters' opinions that hiding the details from
> scripters does them a disservice
Every computer language hides details from programmers/scripters/ users, that's kind of why we have languages. The higher level language the more is hidden.
There are benefits and costs associated with any language design choice made and while we may quibble about the relative value of one decision over another, on the whole I have a lot of faith in choices made by the Apple engineers.
> especially when the hiding of details breaks down when presented with
> the simplest of compound expressions. The recent discussion of implied
> 'get' events is a prime example.
Easy there. These are calls to properties of objects in applications, these may be simple expressions, but not the simplest. Plus, there is no breakdown here. Nearly everyone who asked seemed to be wondering why it behaved that way, I don't think anyone was facing an insurmountable roadbloack or any breakdown of any kind.
These things are much easier to discuss without undo exaggeration.
> Here's another bit of AppleScript deception that bit me recently.
There is no deception here. There is a design choice that benefited many users.
> AppleScript 2.0 has eliminated the disparate string data types
> (string, Unicode text, international text, etc.) and gone to
> Unicode-only strings. Bravo! To provide some level of backward
> compatibility, all of the legacy string data types are viewed as
> synonymous. In other words, on AppleScript 2.0:
>
> set theString to "string"
>
> set theClass to (class of theString) --> 'text'
>
> set theResult to (theClass is string) --> 'true'
>
> However, this aliasing behavior is not extended to list-containment
> evaluation:
That's not deception, your expectations were not realistic. The class text and the class string evaluate as equal, but the class string is not in the list {text}.
>
> In my code that needs to run on both AppleScript 2.0 and AppleScript
> 1.9.x, I had to track down all of my string parameter validations and
> add 'text' to the list of valid data types:
> Without simple-case type aliasing, I never would have expected the
> list-containment case to work. With this aliasing, it took me a bit
> longer to track down the source of the problems.
Either way you would have had to go back and redo your scripts. But without this behavior a lot more scripts would have broken when the change to unicode text was made.
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