Re: solutions to scripting addition terminology confilicts (i.e. the osax namespace problem)
Re: solutions to scripting addition terminology confilicts (i.e. the osax namespace problem)
- Subject: Re: solutions to scripting addition terminology confilicts (i.e. the osax namespace problem)
- From: has <email@hidden>
- Date: Tue, 22 Jan 2002 14:33:32 +0000
Various folk wrote various things about stuff...
[snip]
Okay, I wasn't going to get into this debate, but it seems that there's one
rather obvious option that has been missed so far. So here goes - with the
usual apologies in advance about excess verbosity, unfocussed rambling, etc.
<2c>
IMHO, the problem is a *logistical* one, *not* a technological one. That
doesn't make sense? Read on...
Anyone developing osaxen and/or scriptable applications for AS should know,
right from the start, that namespace conflicts are a risk in AS, and should
take adequate care to avoid them. For better or worse, the shared namespace
is a 'deep' feature of AS, which trades user ease-of-use for developer
convenience/robustness, and I doubt it's going to change any time soon.
Therefore, I'm not going to argue about whether this choice was right or
wrong as I doubt it would change anything anyhow. Things are as they are;
if it's too serious a problem for some folk to deal with then they could
always consider exploring alternate languages to see if there's something
else out there that'd better fit their needs. For the rest of us, I think
finding a solution which works within the current system is more in order.
--
Now, step back for a moment...
Here's what an osax call looks like in an alternate universe where
application keywords don't exist:
tell addition "Standard Additions"
displayDialog(buttonsList:{"OK"}, defaultButton:1, givingUpAfter:10)
end tell
See? A standard handler/function/method call using labelled parameters,
wrapped in a tell block to explicitly target it at a particular scripting
addition. So if this is what you want, this is what you should ask for.
(Not that I expect you'll get it, mind - they'd have to rewrite some big
chunks of the language and kiss backwards-compatibility goodbye.;)
Oh, and while we're at it, how many folks here realise that even something
seemingly simple like:
count of...
is actually:
count()
in disguise? As somebody else already mentioned, most folk using AS
probably don't realise just how far the original designers went to hide as
much geeky language stuff away from folk as possible.
So far then, this approach has more or less eliminated the potential for
namespace conflicts, and applied a clean, logical syntax that any REAL
programmer would be proud to use. In fact, it's not much further to get to
a standard dot-notation system, eg:
myVariable.count()
...in which case, why not just go all the way and use that instead -
eliminating whatever problems are left in using [less precise] tell blocks?
But yes, of course - the down side is that all of this is much less
friendly-looking (especially to novices), which is [I imagine] why AS's
original designers chose to do it differently. And, from a technical
standpoint, I reckon they actually did a pretty good job.
But that's enough daydreaming... let's get back to our beloved conflicted
namespace universe and talk about its problems some more...
--
If namespace conflicts are occurring between osaxen and applications, it's
either because programmer A over there isn't aware of what programmer B
over here is up to and both adopt the same keyword at the same time; or
because programmer A hasn't checked all prior art to ensure he doesn't pick
any keywords that are already in use. Sometimes the mistakes are foolish
ones, conflicting with well-known keywords; other times the conflicts may
be with something quite obscure.
Oh, and something else that hasn't been touched on is the potential for
conflicts between keywords and variable names. This shouldn't be overlooked
either.
So as far as technical solutions go, it seems to me that - short of saying
"to hell with backwards compatibility and English-like syntax", ripping
half the guts out of AS and reimplementing every osax/application call
using standard 'handler call' syntax and doing away with the application
keyword system completely - you won't fix the problem.
--
The OTHER option is for Apple (since its their language) to police the use
of keywords actively and effectively. Conflicts won't occur if developers
don't allow them to. But for that, they need to be aware of what is going
on around them.
Provide developers with a central database** containing a complete list of
all currently-used keywords:
- Insist that they to refer to it before choosing their own keywords.
- Let them add their own keywords to the database, reserving their choices
in advance if necessary.
- Indicate what words/phrases are acceptable as keywords and what aren't -
i.e. a strong naming scheme.****
- Numpties who fail to follow these rules of practice can be dealt with
through peer pressure and ritual humiliation, since it's in everyone's best
interest to stick to it.
IOW, AS's keyword system stands or falls according to whether or not those
using it are willing and and able to behave as good citizens.
As I said at the start, it's really a logistical problem. At the technical
level, you're pretty much stuck with AS's keyword system - for better or
worse - as long as AS exists. However, at the developer/scripter level, it
wouldn't be an issue if everyone could take adequate care not to tread on
each others toes in the first place... but that can only happen if the
resources are made available (and used) to support this.
</2c>
has
**i.e. similar to the record that's kept for file/app creator codes; and,
of course, assuming that this hasn't in fact already been done, and the
problem is that folk aren't using it or are simply unaware of it
****For example, I get quite irritated by osaxen/apps which use compound
words (e.g. 'someVariable', 'some_variable') as keywords, since that is the
only option available to scripters; let the osaxen and apps stick to using
'some variable', since that is their exclusive province. Also, osaxen/apps
that take records as parameters or return them as results shouldn't claim
that those records' property identifiers are keywords - there's no
technical need to do so, and it increases the potential for conflict with
both other osaxen/apps and with the user's own identifiers.