Re: loading a subroutine properly
Re: loading a subroutine properly
- Subject: Re: loading a subroutine properly
- From: email@hidden
- Date: Fri, 2 Feb 2001 17:15:55 -0500
On Thu, 1 Feb 2001 23:22:18 EST, email@hidden wrote in response to Bill
Planey,
>
Forgive me, but I am totally confused by your use of "mother," "daughter",
>
"routine," "subroutine," "locations," and "handler." Let's make sure our
>
terms are in sync (anyone else chime in please).
>
>
subroutine - a slightly dated and less used term from the days when Pascal
>
ruled. "Handler" would be the more current term.
In AppleScript, a subroutine is a specific type of handler. Sayeth the
AppleScript Language Guide, "subroutines, which are handlers for user-defined
commands."
>
handler - an Applescript "subroutine" which performs a task in a modularized
>
way, which may or may not be passed values and which may or may not return a
>
result.
Handler can be a command handlers or a subroutines
>
parent - a programming object which may have children and pass attributes on
>
to them. IMHO, Applescripts really can't be true parents. Much more
>
thoroughly implemented in languages like Java.
Applescript's script objects implement inheritance and delegation, which
requires the relationship of parent and child, or mother and daughter, or
subclass and superclass. The terminology Apple uses is "parent" and "child".
Other languages like Java and C++ have more complex inheritance relationship
(like multiple inheritance, and "mix-ins" [reading that phrase always makes
hungry for Steve's Ice Cream in Massachusetts].) But AppleScript has real
inheritance, just like Objective C or Object Pascal.
>
mother - the female human who bore you
Although confusing in this context, where "parent" and "child" have specific
technical uses, the terms "mother" and "daughter" have a long heritage of use in
defining a smaller or newer thing that is made from a larger or older thing.
Its used in casting and record pressing, in "the mother of all battles", "mother
lode", "mother ship", and "mother country". The confusion result because the
Applescript "parent" and "child" relationship doesn't mean that the child is
made from the parent; it means that the child inherits from the parent, and
delegates back to the parent. So it could be an adopted child or an agent or an
employee, rather than an offspring.
>
Script object - compiled Applescript code which may be treated as a separate
>
entity. Sometimes incorrectly refered to as a child script.
A script object doesn't have to be separately compiled. It can be defined
in-line with a "script Foo" command, or built dynamically and returned as the
result of a function. It can be a child of another script object. If it
doesn't specifically declare what its parent is in a property, its parent is the
main script; the main script's parent is "AppleScript" (the owner of the text
item delimiters).
>
location - a housing asset
I'm confused by this phrase also, since it could mean "location in memory" (the
space occupied by the data, named by the variable name), the location of files
on the disk, or the context of the code's execution (for example, if Bill Planey
were trying to get the result of a script object but didn't know how to use
them, he may try create a context by hand, by putting values in a global
variable.
>
routine - daily humdrum. More humdrum when using a PC.
I see "routine" frequently used as a language-neutral term-of-art to describe
all groupings of code or functionallity. It is an all-encompassing term that
covers subroutines, coroutines, functions, methods, procedures, handlers, lambda
expressions, and other cats and dogs that represent the verbs of computer
programming. Occasionally, "routine" reaches out to cover macros and even code
snippets pasted in in-line, but I think that's going too wide. In AppleScript,
"handler" covers it all
>
child - a programming construct which can inherent characteristics from a
>
parent script. In Applescript, sometimes used as short for script object.
Sayeth the AppleScript Language Guide, "A script object that includes a Parent
property is referred to as a child script object, or child." A child inherits
properties and handlers, and delegates commands back to the parent with the
"continue" command. (Its not just that the child can inherit; it DOES inherit,
unless it defines its own property or handler with the same name.)
>
daughter - the female offspring of a mother (and father - and it takes a man
>
to be a dad)
Tell that to Dolly the sheep. :-) When biologists talk about asexual
reproduction, the say "daughter" and "mother". When an amoeba fissions, the two
half-size amoebas each "daughters"
AppleScript's script objects are very capable things for doing object-oriented
development. They provide the scripter with the ability to take handers and the
data they manipulate, wrap them together, test them thoroughly, and then use and
reuse them as black-box items. The inheritance and delegation capabilities mean
that if you have a working script object, and need to add one more property or
handler, or change how one handler works, you don't have to change the object
and retest everything. You just create a child and focus your efforts on just
the changes.
On this list, most of the discussion of script objects has centered on is using
them in limited ways. Sometimes, they are used as loadable libraries (ignoring
their ability to carry data as well as handlers). Or they are used to
encapsulate data to avoid the bugs that the read and write commands in Standard
Additions has, ignoring their ability to carry handlers as well. And then there
as the experiments we did about a year ago, to see if script objects could have
their handlers redefined dynamically, to provide a "function pointer" like
capability. It worked, but I'm still not sure if this was a legitimate use of
the language, or just exploitation of a chance bug.
And I'll restate Cal's good advice on script objects as well. Most scripters
just don't need them. The vast majority of AppleScript use (and its real
purpose in life) is to manipulate the properties and use the command handlers of
applications. The application defines the objects and the scripter uses them.
And that advice probably applies to many other issues in AppleScript as well.
Formatting numbers? Dealing with the subtleties of different rounding modes?
Correctly dealing with the reference that 'repeat with m in N' produces? Stop
doing the work yourself! Let an application do it. To paraphrase Thomas
Jefferson, "The script does best when it does the least."
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden