Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
- Subject: Re: [the great right-tool-for-the-job debate] Re: Running Subroutines from Other Scripts
- From: has <email@hidden>
- Date: Mon, 26 Aug 2002 12:46:05 +0100
Michael Sullivan wrote:
>
> 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.]
>
>
Now what I'd say here, having done a little OOP, is that the result of
>
*your* script is correct, it's what happens when b doesn't have a
>
"foo()" that doesn't make sense.
Sorry, I probably didn't make my intended point very clear in that last
post. <cough>8KB length limit</cough>:|
It wasn't meant to drift off into a debate about OOP; rather my argument
was that procedural coders who wish to write modular code shouldn't have to
deal with OO issues. (In fact, they shouldn't even need to be aware that
such issues even exist.) The trouble with Steven's suggestion of using the
parent property to 'load' modules is that it _does_ expose these folks to
said OO issues whether they like it or not. Which goes against what we both
seem to agree on: that non-OO coders shouldn't need to deal with OO issues
in order to write their scripts.
Folks who are fortunate enough to understand both procedural/modular and OO
practices are at least in a position to make educated judgements about
which approach to use. Those who don't are best steered well away from such
"expedient but unsafe" practices and towards more conventional techniques
that will do what they need, albeit in much less exciting fashion.
Sorry if this sounds a bit "I know best; do as I say", but the pedagogue in
me won't let go.<g>
-------
Anyway, to follow up on your OO comments, as they're also quite interesting...
>
I wonder if that's always consistent, functions override always, but
>
properties only override if you're in an overridden function.
It seems to be consistent for AppleScript. Other languages, I cannot say
(mainly because I'm not fluent in anything else). But hey, as long as AS is
being "consistent" at something, don't knock it, okay? You don't want to
jinx it.;)
I don't know either if it's a matter of deliberate design, or a result of
the way AS handles static and dynamic binding [1]. But short of making all
variables dynamically bound (which would impact performance), I'm not sure
how else it could be avoided. One of the main features of AS's inheritance
is that it's _not_ a simple static arrangement (as traditional class-based
languages appear to have); in AS, inheritance can also be arbitrarily
defined for [script] objects instantiated during runtime.
This lets you do various things that you can't do in languages where
everything's set in stone at compile-time. For example, you can have
several objects share the same parent _object_, allowing them shared access
to the data in that parent [1]. You can also emulate multiple inheritance
(AS is a single-inheritance language), allowing an object to take any
number and arrangement of other objects as parents [2]. Very slick.
>
This actually a serious bug (or maybe design flaw?) in the OO
>
implementation, IMO. It would begin to matter if between the stack
>
issues and compilation, AS ever became a legitimate candidate for really
>
large scale projects.
Again, I'm not sure if it is or not. Do remember that OOP in AS isn't like
OOP in Python, Java, etc. It's much closer to languages like JavaScript and
Self: prototype-based rather than class-based, and thinking about it simply
in the latter's [more familiar] terms may not be the best approach.
In any case, as Chris N points out, you can still access a parent/child's
properties easily enough; you just need to be explicit by using the 'my'
keyword. (Or, if you want to be a total spod, I guess you could always add
"protected" [3] accessor methods to objects whose state you want to share.
[4])
has
--
[1] Whether this is a good idea in practice is another question, however...
I'm really not sure myself. [It's could also be brittle; e.g. copying such
an object would break the relationship.]
[2] Bearing in mind that you'll need to be extra careful about naming
non-local variables and stuff as they'll all be semi-sharing the same
namespace.
[3] Since I already use "_foo()" for private methods myself, I've taken to
using "__foo()" to represent methods that are less restricted, though still
not part of the published interface. This is perhaps a bit topsy-turvy
though, so find whatever arrangement works best for you and then stick
religiously to it. [A quick read of the Python style guide may help you for
ideas, as Python is well organised in its use of underscore naming schemes
to represent special meaning.]
[4] Just don't blame me when all your friends call you "Dilbert" ;)
_______________________________________________
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.