Re: String to multiple-item list coercion
Re: String to multiple-item list coercion
- Subject: Re: String to multiple-item list coercion
- From: has <email@hidden>
- Date: Thu, 26 Sep 2002 12:28:40 +0100
Michelle Steiner wrote:
>
That was my point.
>
>
--Michelle
>
>
On Wednesday, September 25, 2002, at 02:36 PM, has wrote:
>
>
> And what you're seeing here is the last statement - {a, b, c, d, e} -
>
> being
>
> evaluated.
Mmmm... sorry, there must've be some confusion over what was meant. Okay,
at the risk of turning this into a last-minute rant: I will try to bury
this issue once and for all, and may god have pity upon its miserable
soul... :p
My point with:
set {a, b, c, d, e} to "abcdefgh"
return result
--> "abcdefgh"
was that there was no sign of the string being coerced, not on the
right-hand side where you usually see such things. [Note: I've added
explicit return statements for readability's sake; no change in behaviour
though.]
While with this:
set {a, b, c, d, e} to "abcdefgh"
return {a, b, c, d, e}
--> {"a", "b", "c", "d", "e"}
I wasn't sure if folk were being confused by the end result being a list,
and somehow assuming it's a list because the multiple assignment made it
into one.
Meanwhile:
set {day:a, month:b, year:c} to date "Sunday, September 1, 2002
12:00:00am"
return result
--> date "Sunday, September 1, 2002 12:00:00 AM"
and:
set {day:a, month:b, year:c} to date "Sunday, September 1, 2002
12:00:00am"
return {a, b, c}
--> {1, September, 2002}
are directly equivalent to the previous two examples, except that
assignments are made according to labels rather than position.
If we follow Steven's original logic that a multiple assignment with list
on left and string on right invokes an atypical item->list invisible
coercion, then by extension there must be an invisible date->record
coercion happening in my date example as well. Yet anything->list coercions
in AS invariably produce single-item lists, while there's no
anything->record coercions supported at all. So Steven's theory looks
pretty shaky; plus there's a far simpler explanation anyhow: that as long
as the objects on each side both understand 'items', or both understand
'properties' [1], then a multiple assignment is possible, practical, and
needs no special explanation requiring bizarre and unseen behaviours to
explain.
I'm NOT trying to be rude or condescending to anyone. However, aside from
making a fair point about 'item of "some string"' not being documented, I
thought Steven's assessment was flawed and wrong, and unhelpful and
potentially misleading to anyone else reading this thread. I'll bet you 99%
that I'm right, but unless somebody wants to dig up and reanimate the
corpse of our already much-missed C. Nebel [AS List Veteran and Hero, 199?
to 2002] then I don't think anyone else can do better than that.
--
And now, may we all hope this rather wretched thread can RIP, so I can go
find something else new and interesting to slowly belabour to death for a
change... ;p
has
[1] Obligatory caveat: the choice of objects allowed on the left side is
fairly limited though, basically either list or record. For reasons that
should be common-sense enough to figure out, you can't have a record on the
right and a date on the left; or a list on the right and a string on the
left.
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.