Paul Berkowitz wrote:
> >> NSDictionary
> >> is precisely a "rigid" immutable data structure: it's much more rigid than
> >> an AS record in that you can't change the value of keys.
> >
> > Ouch. There goes my bullshit meter, redlining again.
> >
> > NSMutableString* s =
> > [NSMutableString stringWithString:@"howdy"];
> > NSDictionary* d =
> > [NSDictionary dictionaryWithObject:s forKey:@"greeting"];
> > NSLog(@"%@",d); // {greeting = howdy; }
> > [s setString: @"hello"];
> > NSLog(@"%@",d); // {greeting = hello; }
> >
> > No "more rigid" than an AS record. m.
>
>Sure it is. That's a trick answer that you've set up to get around the
>limitations.
Yep, that's changing the content of the value of the key, not changing the value of the key. The NSDictionary's 'immutability' applies only to itself; it does not magically confer immutability upon all the objects it contains. This is as it should be. I think Matt's BS meter needs a tune-up on this one. :)
>An AppleScript record
>is somewhere between the two types (no equivalent of removeObjectForKey: or
>setObject:forKey: although there are easy ways to redefine a record to do
>those).
A little knowledge is a dangerous thing, as they say. I think that because you know a little about the underlying implementation, you're confusing implementation for interface. Yes, AppleScript *implements* record and script object properties as associative lists - but according to your faulty logic, this means that AppleScript records and script objects *are themselves* associative lists. It's like saying that because an automobile is powered by a combustion engine, an automobile *is* a combustion engine. Obviously incorrect.
Ignore the internal implementation details; forget that AppleScript records are bridged to key-value lists (AERecord descriptors) and AERecords to hash tables (NSDictionaries [1]). Pay no attention to that man behind the curtain. See an AppleScript record for what it is in AppleScript: it's a collection of properties, i.e. first-class objects bound to *identifiers*. Look at a dictionary: it's a collection of first-class objects associated with other *first-class objects*. Because this is the crucial point:
First-class object != Identifier
Just because you can dive down a level to C where AppleScript identifiers are represented as long and char* and mangle them there doesn't change what records are in AppleScript: a collection of properties. Just as a C struct is a collection of properties, even though you can dive down a level by casting it and screwing around with its contents using raw pointer math.
Abstractions exist for a reason. See them for what they are; not how you can hack your way into, through and around them all the time. It's a sign you've been spending too much time around AppleScript when you're constantly doing that. ;)
has
[1] At least I think NSDictionaries are implemented as hash tables. They could also be implemented as key-value lists, balanced B-trees, skiplists or any of a dozen other data structures. And you'll never know from looking, because these internal details are abstracted away precisely because they're utterly irrelevant to what these objects do and how you use them.
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-studio mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/applescript-studio/email@hidden
This email sent to email@hidden