• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Dates gone wild
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dates gone wild


  • Subject: Re: Dates gone wild
  • From: Axel Luttgens <email@hidden>
  • Date: Wed, 10 Sep 2003 00:15:56 +0200

Here comes second part...
(of course, those who already got bored with first part may just skip this one too ;-) )

Doug McNutt wrote:

At 10:10 +0100 9/9/03, Nigel Garvey wrote:


Paul Berkowitz wrote on Mon, 08 Sep 2003 21:05:38 -0700:


[...]


[...]



[...]


I ended my previous post by introducing (somewhat abruptly, I agree) the operators 'a reference to' and 'contents of'.
That's because it is not obvious to create references in pure (ie without interacting with applications) AppleScript ***AND*** to be sure that one indeed has references.
One of the reasons is that AppleScript normally tends to evaluate everything.

So, taking for granted that the 'a reference to' operator really yields a reference, let's consider this:

set d to 1
set x to item 2 of (a reference to d)
--> error: can't get item 2 of 1

Above script fails because AppleScript evaluates the reference and immediately tries to take value's second item.
A similar, but yet subtly different, behavior holds with this code:

set d to 1
set x to a reference to item 2 of d
x
--> item 2 of 1

Here, d got immediately evaluated, but the 'a reference to' operator blocked the evaluation of the 'item 2 of' part of the expression: x now truly contains a reference, even if not a very useful one (just try to evaluate it by taking its contents, even after having changed value of d).

In the same vein, but more useful for an illustration of the reference concept:

-- Create a reference to a non-existent value
set d to 1
set x to a reference to item 2 of (a reference to d)
x
--> item 2 of d of <<script>>
-- Now, set d to a list and evaluate the reference
set d to {1,2,3}
contents of x
--> 2
set item 2 of d to 200
contents of x
--> 200

Through above example, it should be clear that x can't be assimilated to a pointer (not even a handle), as its value has been created before the value it should have pointed to...
As a consequence, this is also very different from data sharing.

Now, instead of the above artificial example, consider some statement such as:

tell application "TheApp" to set w to first window

If 'TheApp' returns a reference within such a context, w allows you to allways act upon first window (let's say the front one), whatever the user does with the application's windows (opening new ones, bringing another one in front...).

Internally, I guess one is now using a more elaborated structure than the one I supposed in my first post, so as to be able to take into account the various properties (and the ways to refer to them) of the involved objects.


We have been down this turnpike before and I remain frustrated. If someone would use precise terms to define "reference" instead of saying fuzzy things like "It's much higher level than a pointer." Or "It's all text." perhaps we could get it straight.


Conceptually, that idea of textual replacement should not be a too misleading one (even if surely not a description of AppleScript's internals).

Now, when do we encounter references in AppleScript?
If one could tell it, it could be a step towards a definition.

I never managed to do more than just enumerate the different cases I could think of:

writing some kinds of basic expressions (see below)
using the 'a reference to' operator
using a 'repeat with x in' loop (x will contain consecutive references)
asking an application to return a reference

(any other ideas?)

Another approach would be to provide some kind of operational definition; the only one I could ever devise is the following one:

An AppleScript expression
Expr
is a reference (or more generally, involves reference(s)) if
and only if
Expr = contents of Expr
evaluates to false.

(counter-examples?)

Some examples:

-- An index reference form is not a reference
item 1 of {1, 2} = contents of (item 1 of {1, 2})
--> true

-- Unless you put it in a list expression
{item 1 of {1, 2}} = contents of ({item 1 of {1, 2}})
--> false

-- But such a reference vanishes through evaluation
set x to {item 1 of {1, 2}}
x = contents of x
--> true


Actually it seems to me that references are used when the AppleScript compiler finds an expression "complicated enough" to use them. set and copy do the same thing for simple things but set installs a reference when, in the compiler's opinion, things are complicated enough to warrant it.


Did you mean 'reference' or 'pointer' here?

In this case the list contains only one item of class date; would it behave the same way if there were 100 items?


Yes (if I correctly understood your question).

What if the object contains 2000 characters?


Strings are not liable to data sharing:

set x to "abcdefg"
set y to x
set x to "hijklmn"
x
--> "hijklmn"
y
--> "abcdefg"

nor are they references:

set x to "abcdefg"
x = contents of x
--> true

What about being in a tell block?


You are thinking about something, but I tried very hard and still don't understand :-)

When does a variable become an object? (Isn't everything supposed to be an object?)


Perhaps should it be better to just think about variables as a means to name/refer values.

[...]



Hmmm...
Really HTH,
Axel
_______________________________________________
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.

  • Follow-Ups:
    • Re: Dates gone wild
      • From: Walter Ian Kaye <email@hidden>
    • Re: Dates gone wild
      • From: Emmanuel <email@hidden>
    • Re: Re: Dates gone wild
      • From: Helmut Fuchs <email@hidden>
References: 
 >Re: Dates gone wild (From: Nigel Garvey <email@hidden>)
 >Re: Dates gone wild (From: Doug McNutt <email@hidden>)

  • Prev by Date: Re: Dates gone wild
  • Next by Date: Re: Doubt
  • Previous by thread: Re: Dates gone wild
  • Next by thread: Re: Re: Dates gone wild
  • Index(es):
    • Date
    • Thread