Re: Adobe's lousy AppleScript implementations
Re: Adobe's lousy AppleScript implementations
- Subject: Re: Adobe's lousy AppleScript implementations
- From: has <email@hidden>
- Date: Mon, 30 Sep 2002 18:00:08 +0100
Shane Stanley wrote:
>
>Which is to miss the whole point, sorry.
>
>
>
Interesting to speculate how the point might have been missed.
By all means; and perhaps I'll learn to better express myself next time.
Although, something to consider first:
I'd love to spend more time laying the groundwork for a really good,
comprehensive explanation, using canonical examples as demonstration, Q&A,
etc. But the limitations of a mailing list post, time, the need to get on
with my own work, and everyone else's desire to find a workable solution by
the shortest means possible means there's going to be some pretty severe
compromises along the way.
But if the result is too much of a mess to be _any_ use at all, then please
at least point out some _specific_ areas I can improve on so I can try to
recover some of it.
>
I suspect its
>
lack of flexibility ("it should - no, *must*", "not one word more",)
Actually, I thought my _two_original_posts_ containing explanation and code
were the very model of restrained language [for me;]. So I don't think
that's the problem.
If I'm blunt in the reply to Michael's post (sorry mate), it's because my
primary point seems to have been missed - suggesting I didn't emphasise its
importance enough originally.
Put simply, that point was this: if you're going to squeeze the excess
complexity out of your system, squeeze as hard as you can. Don't just give
it a half-hearted little shake and declare that's as good as it's going to
get, cos you're only fooling yourself then. [And if you don't already have
the skills to thrash the thing to an inch of its life and back again, then
it might be a really good time to develop them.]
He was also wrong in stating the system required a script server to
function, btw, but that was secondary. A script server might be a
convenient way to wrap it all up for some cases, but was never a part of
the main debate.
...
>
and overall complexity might have something to do with it.
I don't think anyone's claiming the design + code I posted was simpler than
David's original: it's three-quarters architecture, after all. But then,
you're not dealing with just one bit of code like he posted; you're dealing
with a _dozen-plus_ of the things. Plus it's only going to get worse - i.e.
fatter and more convoluted - as new functions and support for additional
"non-standard" applications are added in future.
So either you deal with a dozen "simple" algorithms, none of which is too
taxing by itself but when all added together amount to anything but a
"simple" task to develop and extend; or you bite the bullet, consolidate
the lot, and give yourself an clean, extensible structure that will scale
easily for as far as you want it to.
Now, if anyone can come up with a simpler and more code-efficient system,
please, be my guest. I'm still learning too, you know. Otherwise tell me
where I'm causing confusion so I can make my explanation/code easier to
understand. If not... well, there's not a lot else I can do to improve what
I've written. :(
Regards,
has
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
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.