[the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
[the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
- Subject: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
- From: has <email@hidden>
- Date: Mon, 26 Aug 2002 00:36:24 +0100
[With apologies...:]
Steven Angier wrote:
>
[...] provided that the top-level parent in the loaded
>
library has not been changed to something other than AppleScript.
That's another assumption/requirement one shouldn't have to make.
>
> By using modular construction, you break your design up [...]
>
>
I do not dispute this, however AppleScript doesn't care if you use modular
>
construction or not. It is a matter of personal preference
Quite. [Just to clarify: I put that bit in for background, so I'd have
something to contrast against later for the benefit of any readers who
aren't familiar with modular concepts. I didn't mean it to distract from
the argument proper.]
Anyway, given that the OP here did want to be modular, the topic for
discussion is on the best way to do this. So on we go...
--
>
I once worked with a FileMaker Pro developer who, as part of another
>
solution, created a suite of files of amazing linear complexity: hundreds of
>
fields in each; hundreds of scripts. [...]
>
>
My belief is that this person was more brilliant than all of us put together
Sounds like an idiot to me [1]. Perhaps someone should have taken him aside
and beaten him with a big copy of "Database Design for Dummies", followed
by "Relations for the Recklessly iRResponsible" and "Normalisation for
Nitwits"? :O)
I do hope you're _not_ holding this up as some sort of example of modular
design though, because I'd say it's the absolute antithesis of it. Indeed,
it sounds much on a par with the "five hundred lines of code with not a
single handler, and proud of it" school of coding.
--
>
> Returning to the problem with the "simplest" approach of using
>
>inheritance [...]
>
>
Our base
>
library (the one with a couple hundred functions in it) really belongs in
>
the same namespace as AppleScript itself, because all of the functions in it
>
(with a few exceptions) serve to augment and complete features of the
>
language.
Yes and no. I agree that the types of functions your library provides
should be bundled with the language by default. I don't agree with adding
more and more stuff to the primary namespace, however, because all you'll
do is progressively clutter the place up. And with the ground constantly
shifting under their feet, after a while users won't know where to stand
any more for fear of trampling on top of the whizzy new stuff that's being
shovelled in under them. Users need a safe, known space to work in where
unexpected surprises aren't suddenly going to pop up from under them.[See
the osaxen/namespace debates that have cropped up previously for more
reading.]
--
>
For example, if I am working with an AppleScript list, I might want to
>
arbitrarily find the offset to specific items in the list, or find only the
>
unique items, or remove specific items, or sort the list. Unfortunately,
>
AppleScript lists aren't that sophisticated. I might then want to load a
>
library which contains functions that allow me manipulate lists in this way.
>
I will want that functionality to be a parent to all AppleScript list
>
objects I create
The fact that you _can't_ attach additional functionality to AS's built-in
types is one of the things that often annoys me. (You might recall me
posting some code for subclassing AS lists a few weeks back, and expressing
my annoyance at the extreme clumsiness of it all back then.) But I don't
consider dumping these extra functions into the global space to be a
particularly good or relevant answer.
[It's certainly not making "that functionality ... a parent to all
AppleScript list objects"; I think maybe you've confused your terminology
or mental map of AS here? (Which you're not allowed to do, because that's
_my_ job.;)]
And what's so awful with using "listLib's listOffsets(x)" anyway?
>
I feel that some things belong on their own in their own little namespace;
>
but it often makes sense (to me at least) to have some functionality as part
>
of the global namespace.
Mmmm, I'm sure strings, booleans, integers and every other comer will be
able to find many great uses for listOffsets() as well. ;p
--
>
Namespaces aren't always convenient or appropriate. Imagine if C-based
>
languages made us refer to ALL of its libraries in their own namespaces:
>
>
stdio.printf("Hello world from the stdio.h namstpace!\n");
<sarcasm>Because everyone knows that C is the pinnacle of language design;
so safe and simple that even your granny could use.</sarcasm>
(Well, you did rather ask for it there - I mean, waving a "Cee" example at
_me_ of all people. Pure red rag to a bull...;)
--
>
> p.s. [...]the criticism is aimed entirely back at myself... (or, more
>
> accurately, at the 100x worse coder I used to be:).
>
>
At 100x improvement, it shouldn't be long before your scripts take over the
>
world :-)
Q1a. If Hamish's programming skills initially improved 10x after 2
months and by a further 10x after 2 years, express his learning curve in
Big-O notation.
Q1b. For extra credit, given the performance characteristics expressed
in Q1a and bearing in mind that Hamish couldn't originally code for s**t,
estimate the time from now until he takes over the world. (Hint: you'll
probably need a bigger calculator for this.)
>
> [3] For example, if script A has a handler called "foo()", and script B,
>
> which inherits from A [blah-blah-blah]
>
>
I'm not sure what you mean here. If you mean something along the lines of
>
the following code, then this is exactly what I would expect.
[snip]
No, I meant something like this:
======================================================================
script a
property x : "a"
on foo()
return x
end foo
on bar()
foo()
end bar
end script
script b
property parent : a
property x : "b"
on foo()
return x
end foo
end script
b's bar() --> "whoops!"
======================================================================
Script a's 'bar' suddenly starts behaving differently to how it would have
had b not had a handler called 'foo' also. And since we're not meant to be
teaching anyone OOP here, why are we suddenly exposing procedural folks to
*upcalls* of all things?
[Ditto with the "b's parent's foo()" stuff, btw. Module users shouldn't
ever have to know or use such a beast.]
>
> this is good as impossible with something like [e.g.]
>
> Steven's [closed-source] library
>
>
Nearly all of the functions are documented in the supplied dictionary,
Which is excellently done, btw, and should be held up as a model to the
rest of us, but doesn't solve the problem as such...
>
The rest use underscores to help avoid collisions.
Ummm... I take it you mean like:
_hiThereIBelongToHamish()
or:
__IBelongToHamishToo()
Hate to say, but I use those too - for *my* private handlers. Underscores
will not keep you safe either. [2]
Cheers,
has
(Just because you *can* do a thing doesn't mean you *should* [3])
--
[1] Suffice to say that smart people frequently make for much bigger idiots
than dumb ones. When dumb folks dig a hole for themselves they're using a
shovel at most; when the smart ones do it, they bring a whole fleet of JCBs
with them. [1a]
[1a] Note: being as I am both dumb _and_ idiotic, you may think of me as
the exception that further proves this rule.;)
[2] In fact, so paranoid am I now that I've begun prefixing all private
methods in objects that are intended for subclassing, just so I can put in
the documentation that users must NEVER name any of their own stuff
beginning [e.g.] "_AR..." otherwise I'm going to come after them, Freddy
Kruger-style, and then they'll be *really* sorry. But since AS has no way
to enforce private scoping rules, defining your own pseudo-namespace like
this is really the only option left open to you.
[3] Boy, I bet my parents often wish they'd thought of this one some XX
years ago. And probably everyone on this list as well by now.;) Steve, if
you'd like to continue this thread then how about we take it off-list?
(Before we send any more ASUL readers into a terminal coma...<g>)
_______________________________________________
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.