Re: Date Variables that modify themselves! Huh?
Re: Date Variables that modify themselves! Huh?
- Subject: Re: Date Variables that modify themselves! Huh?
- From: John W Baxter <email@hidden>
- Date: Wed, 4 Jul 2001 12:58:01 -0700
At 9:58 -0700 7/4/2001, Paul Berkowitz wrote:
>
On 7/4/01 7:29 AM, "Michelle Steiner" <email@hidden> wrote:
>
>
> "time" is a record. When you set one record equal to another record,
>
> they're the same record. So, when you change one of them, the other is
>
> changed also, because they're the same thing.
>
>
<snip>
>
>
> So, if you rewrite your second set to
>
>
>
> copy DateTimeNow to DateTimeSend
>
>
>
> you will not have this problem.
>
>
All this makes sense if the date value class actually is a record, as it
>
almost appears to be. The different behavior of set/copy as demonstrated by
>
everyone seems to indicate that this is the case.
>
>
It's odd that the ASLG doesn't come right out and say so. It just says
>
(p.62):
>
>
A complete Date value specifies the day of the week, the date (month, day of
>
the month, and year), and the time; if you provide only some of this
>
information, AppleScript fills in the missing pieces with default values.
>
You can get and set properties of a Date value that correspond to different
>
parts of the date and time information.
>
>
>
And again on p.64:
>
>
You can refer to properties of a Date value using the Property reference
>
form.
>
>
>
That certainly sounds just like a record. But it doesn't present itself as a
>
record, with record braces and labels, and won't coerce to one (without
>
Tanaka's osax). Enabling it to do so might have made its 'record'-like
>
behavior clearer.
>
>
In fact, a date's coercion to a single-item list rather than to a multi-item
>
list, and its coercion to a string, is distinctly non-record like. Records
>
don't do either of those things. It's not a true record, or it's one with
>
unusual, exceptional qualities.
>
>
Its contrasting copy/set behavior should be spelled out somewhere. I've
>
never stumbled over this myself, although I have idly wondered a few times
>
why Emmanuel Levy's excellent short-date handler included the line
>
>
copy d to f
>
>
Now I know.
>
The date type seems to wear many faces. When AppleScript ships one via an
Apple event, it is packaged up as type 'ldt ' (trailing space) whose value
is a 64 bit integer.
I think that's how AppleScript deals with it internally, as well...with a
bunch of handy stuff added. As hinted at by
set d to date "Friday, January 1, 1904 0:00:00"
set dd to d - 3 * days
display dialog dd as string
--correctly displays Tuesday, December 29, 1903 0:00:00
The modern 64-bit date stuff in Mac OS does that (the original 32-bit date
stuff didn't).
We know experimentally that it is shared by the set command...as a record
would be.
We also know that it acts like a record in some ways...but not all.
I generally think of it as "a date" without trying to think "it's like a...".
--john
--
John Baxter email@hidden Port Ludlow, WA, USA