Re: Date Variables that modify themselves! Huh?
Re: Date Variables that modify themselves! Huh?
- Subject: Re: Date Variables that modify themselves! Huh?
- From: Paul Berkowitz <email@hidden>
- Date: Wed, 04 Jul 2001 09:58:51 -0700
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.
--
Paul Berkowitz