Re: when to use "copy" vs "set" [was Re: Manipulating text]
Re: when to use "copy" vs "set" [was Re: Manipulating text]
- Subject: Re: when to use "copy" vs "set" [was Re: Manipulating text]
- From: has <email@hidden>
- Date: Sat, 26 Sep 2009 17:54:34 +0100
Mark J. Reed wrote:
This is where what's going on behind the scenes matters.
Sort of. You shouldn't need to know the exact mechanics, only the
rules that they follow. (The exception is if the mechanics themselves
are flawed, in which case you need to know internal details in order
to deal with those flaws - but that's why they're called flaws.)
When a variable holds a simple scalar value - number or string - it
contains
the whole thing as it's value, and set copies that value. When a
varIable "holds" a list or record or date or other object, its value
is really just a pointer to the actual structure.
In terms of implementation, I believe that the AS interpreter uses the
same approach as the Ruby interpreter. C longs (which are 4- or 8-
bytes, depending if the executable is 32- or 64-bit) are used to keep
track of AS objects within the interpreter. If the object is an
AppleScript integer, it is stored directly in the upper 30/62 bits of
that long; any other AppleScript object is stored in heap-allocated
memory, and a pointer to that memory location is stored in the same C
long. The bottom bit of the C long is set to either 0 or 1 to indicate
if it contains a number or a pointer.
Note, however, that from the AppleScript user's point of view, all of
this is - or should be - *completely irrelevant*. Indeed, if you have
to explain this to AS users, then there is something deeply defective
in the design of the language, which is supposed to hide all this
complicated low-level gubbins from users for a reason. Otherwise,
what's the point of using a high-level language like AS instead of low-
level C in the first place?
So, as far as scripts are concerned, all classes of data in
AppleScript are represented as first-class objects which can be stored
in variables, used as parameters to commands, etc. in exactly the same
way. The only thing that distinguishes integer and string objects from
list and record objects is that the first two types of object are
immutable (i.e. you cannot change their contents) while the last two
are mutable.
This part of the language is really quite simple. The main problems are:
1. It can be hard to tease out these parts of the language from other
areas that are rather more complicated (e.g. the IPC stuff) so that
you can make sense of them in isolation.
2. Certain concepts have never been well explained in Apple's own
documentation, which seems to have a mad fear of using certain
explanations - perhaps because they'll sound too technical or 'real
programmer-y' to this particular audience's ears. In this case, I
remember all the rubbish about 'data sharing' in the old ASLG causing
me no end of confusion - until I began learning about other languages
where they just explained this object vs variable and mutable vs
immutable stuff straight, and subsequently realised that was what AS
was doing as well.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
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