Is there a label, goto handler like in basic?

Scripting Forums AppleScript | Mac OS X
#1

I checked the archives for this one and I couldn’t find anything… :confused:

I wanna be able to label chunks of code and depending on buttons pressed at the beginning, I want the script to call upon different peices. As it is, I’m having to copy the entire script several times over and modify each if then statement according to the button pressed since I don’t know how to do some sort of labeling.

Example:

[code]display dialog “blah” buttons {“do a and b”, “do b and c”, “do a and c”}
copy result as list to {btn_pressed}

label a
–chunk of code
end label

label b
–chunk of code
end label

label c
–chunk of code
end label

if btn_pressed is “do a and b” then
goto a
goto b
end if

if btn_pressed is “do b and c” then
goto b
goto c
end if

if btn_pressed is “do a and c” then
goto a
goto c
end if[/code]

#2

those are called methods or subroutines (or sometimes even procedures)

try something like this:

display dialog "blah" buttons {"do a", "do b", "do c"}
copy result as list to {btn_pressed}

if btn_pressed = "do a" then
	a()
else if btn_pressed = "do b" then
	b()
else
	c()
end if

on a()
	display dialog "You pressed a!"
end a

on b()
	display dialog "You pressed b!"
end b

on c()
	display dialog "You pressed c!"
end c

the brackets are for the optional parameters you might want for your subroutine.

#3

Nitpick: copy creates an actual copy of the data in memory, which can make it less efficient than the set command. You should only use AppleScript’s copy command when you want to explicitly avoid data sharing.

Also, I’d use something like this:

set {button returned:btn_pressed} to result

Edit: See also:
About Subroutines
Defining and Calling Subroutines

#4

  1. The goto model is awful, terrible, evil design. (It sorta sounds like you’re confusing goto with other concepts, though. Do you know the difference?)

  2. Immutable objects, behind the scenes, are typically not copied when sent a copy message. Because they are not designed to be altered once initialized, they’re simply retained. There’s no reason to copy data that cannot change, because duplicating objects is an expensive operation.

edit: If the AppleScript system does #2 differently, I certainly hope it’s justified somehow.

#5

yeah, i was merely using his script as an example. I was kind of in a rush. Had to go to driving lessons :smiley:

#6

Thanks Hendo13! That was exactly what I was looking for. Also thanks to Bruce for pointing out the difference between copy and set. :wink: I wouldn’t of figured that out by myself for a long time.

#7

No problem :wink:
Just remember if you have to call a subroutine within another subroutine you use my

Example

on somemethod()
set sometext to "something"
my othermethod(sometext)
end somemethod

on othermethod(stuff)
yaddyaddya
end othermethod
#8

No, Sir,

Just remember if you have to call a subroutine within a tell block you use my

just a subroutine doesn’t matter

#9

oh yeah woops, forgot about that:P

The reason you do this Sk8.4Life. is because when you are calling a subroutine from inside a tell block is because you need to make sure that you are able to distinguish between your subroutine and application keywords…I think thats why:P
StefanK might have to correct me again on that one;)

#10

:smiley:

the reason is:
only AppleScript itself knows, what a handler is, nothing else :wink:

#11

Or sometimes AppleScript just wants to be annoying. I usually try to remember to put “my” in front of all my own handler calls, no matter where the call is made. I just got tired of the inconsistant behavior without it. :stuck_out_tongue:

#12

…

Thanks for the info. (I’m not sure if AppleScript handles this differently.)

#13

Heh, it seems I brought up a good question. :wink: I’m glad so many people are around to help out and it seems I’m not the only one who learned a thing or two here. :smiley: I’ll definitely be bookmarking this topic for future reference. :slight_smile:

#14

Chris Nebel, AppleScript’s insider on the AppleScript-User’s mailing list, told me the same thing a few years ago. Apparently, the reason ‘copy’ still takes slightly longer than ‘set’ with immutable objects is that it first has to identify whether the objects are mutable or not!

Personally, I think that ‘copy’ should only be used when you want to duplicate data, to make it obvious that that’s what’s specifically intended at that point in the script.

#15

There’s no way it takes so long that it matters, if we’re talking about AppleScript. I mean, it’s not a performance language. (Not that optimization isn’t important, but I wouldn’t bet on it being very much at all. We’re talking almost nothing, here.) (Edit: But yeah, if you don’t need to copy, you may as well not.)

Copy should be used when the object’s intent is to have a copy of the data. This is an opaque operation, usually; the object should not know or care about whether the data is actually copied. That machinery is “behind the curtain” and not necessarily the concern of your object, which is that it has access to data that has not been modified by unknown, outside sources. In the actual event that you HAVE to have a separate copy–say, some sort of threaded class–there are ways of making that happen, of course. (-copyWithZone: for example)

If you want to make your intent clear in the code, use comments; don’t assume that using APIs in any particular way will convey meaning.

#16

Well yes. We are. :wink:

But as a performance-orientated user of the language, such things interest me. At the time Chris imparted the above information, it had seemed logical to me that ‘set’ would be implemented always to set and ‘copy’ always to copy. The description of ‘copy’ on page 132 of the AppleScript Language Guide says “The Copy command is an AppleScript command that makes a copy of one or more values and stores the result in one or more variables” and doesn’t contradict that even in the section on data sharing. ‘Set’ is always faster than ‘copy’, even with non-mutable data, even if only minutely. I was therefore sure that ‘copy’ had been implemented in the way I’d supposed. Chris was just setting me straight on that point and explaining the timing difference.

A strange language you speak. :confused: I was talking of the scripter’s intentions and the clarity of the written script.

I was thinking of highlighting the meaning more than merely conveying it. An occasional use of ‘copy’ will stand out more in a sea of ‘sets’ than it will when the whole script’s awash with casually used ‘copys’ “ comments or no comments. :slight_smile:

#17

Intentions are not expressed in code; code is a product of intention. Clarity also has little to do with what functions are used. If you have a real need to express intention, comment your code with something that describes the goal of the function/line/loop/whatever.

Don’t assume that using one command over another will convey any kind of meaning. That is the point of comments and other documentation.

Edit: It isn’t that code can’t convey some kind of intention to a reader, but that assuming it does is folly; the method name may describe its intended behaviour, but not its purpose in your situation.

More edit:

The idea is that your object shouldn’t be aware of the implementation details of another object.

(And again, yeah, if you don’t need to issue a copy command, there’s no reason to do so.)

#18

If we’re talking about one instance, it’s not all that noticeable. But put it in a repeat loop (or a nested repeat) and you WILL see a horrible performance hit. AS is very very odd in that respect. Simple phrasing differences will result in one handler roaring like a lion and another dragging like a snail. I learned that the hard way while I was working on sort routines in AS. eh, Nigel? :wink:

#19

It’s not just a matter of speed, if that’s what you’re implying. If a method of your object intends on creating a copy of another object, and that results in an actual copy (and it very well may), that’s additional memory allocation. There’s no reason to use memory you don’t need, especially when it requires equivalent or more typing than not doing so. :wink:

I mostly just wanted to clear up some ideas about the concept of “copying” objects and the “midget in a soda machine” behaviour of well-designed objects.

#20

No, wasn’t implying that. I am aware that the more memory you use, the more likely you are to cause nasty things like page outs and page ins, slowing performance. I just meant that while a copy isn’t all that costly when it is only one copy, when you’re sorting a list and (say) using an insert sort and creating new items for a list of 1000 items, suddenly that copy time becomes dreadfully important.

Uh, OK. I guess I’ve never heard it described like that before. What do you mean by “midget in a soda machine?” :cool: