Is there a label, goto handler like in basic?

Scripting Forums AppleScript | Mac OS X
#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:

#21

It’s a metaphor for encapsulation and modularity. The more you tie the implementation of one class or object’s internals to another, the more the simplicity of your design will fall. (It also impacts the reusability of the code you write.) Controller classes, of course, are often custom for their situations, but internally their methods should remain as independent as possible, to make augmentations and additions easier.

Imagine a soda machine. You walk up to it, put in a dollar, press the drink button, and you get the drink you wanted. It shouldn’t matter to you how it works internally; all that matters is it took your dollar and gave you the selection you wanted–and if it didn’t have your selection, it would inform you. You could assume that there’s a complex machine inside, or maybe there’s just a midget with chilled cans of soda in a cooler, and he dispenses the cans when there’s a dollar and a selection. But that isn’t your concern. All you should care about is how you interface with the soda machine.

#22

Ah. OK, I know the concept, but hadn’t heard it quite described like that - we always used the “black box” concept - input goes in (or a method is called) and you get out what you want, regardless of how it works. It could be rewritten 18 different ways as long as you get out what you expect. If you have a “black box” that coughs up sine values, doesn’t matter if it looks them up in a table or computes them as long as they’re right.

(silly story) Years ago I learned a very arcane programming language called RPG II (an IBM oddity of a language). It had its own fixed logic - input, then processing, then reports generated - no deviation! That process could be augmented by “flipping switches” by putting characters in certain columns of your “program.” It was a horrible language - I think IBM tried to “dumb down” the idea of a programming language but they actually created something that only a programmer could begin to understand.

My instructor at the time used the idea of a little “RPG man” running around in the computer like Mario from Donkey Kong. pushing buttons and pulling levers to get the machine to do the right thing. Your “midget in a soda machine” evoked that “RPG man.”

#23

IBM developed RPG originally as a query language for punch card machines, which explains its form, I suppose:

http://en.wikipedia.org/wiki/RPG_programming_language

Hats off to anyone who uses it today.