Re: Do shell script and special characters
Re: Do shell script and special characters
- Subject: Re: Do shell script and special characters
- From: has <email@hidden>
- Date: Fri, 25 Oct 2002 21:51:27 +0100
Goode sirre Knapp didst pene in fineste-most quill worke:
>
> No, no, no. Call me old-fashioned,
>
>
You're old fashion.
Deare sirre, thou hast qwite forgottest thine "ed"! Didst thou droppe it
sumplayce, mayhap in accidente?
>
While we are *waiting* for yet
>
another update to fix yet more bugs, it would be nice for advanced users
>
to have the means of creating their own temporary solutions.
Thou meanest thate thou dost wante a "hacke". Dost thou not feele thou
alreade hast enoughe"hackes" alreadye? Howe manyee hackes woudst thou
likest to hav?
>
A good example is the problem many of us are encountering with Unicode
>
text. Many, (and I do mean many), applications simply do not *yet*
>
recognise Unicode. Eventually all Mac apps will handle Unicode as a matter
>
of course, but currently they do not. That is why it would be nice to have
>
an "as plain text" coercion.
Deare sirre... (ahh, f**k it; this joke is old already)
I'm going to agree that there should be a comprehensive built-in set of
coercions between different AS text types. As it stands, AS is horribly
patchy in places; this is not news. But that's _not_ what you were asking
for in your last post. [Not trying to pull a fast one, are you...?;p]
There's a huge difference between wanting AS to work sensibly, and wanting
byte-level access to guddle around in datatypes any old way you see fit.
Some languages happily allow that kind of behaviour because it's in keeping
with their general philosophy. Other languages do not because it would be
counter to _their_ remit. If you want a language that does absolutely
_everything_ (just because it can), try something like Perl or C++. Don't
say all tastes aren't catered for. Just don't expect a single language to
cater for all tastes; otherwise, what's the point of having multiple
languages in the first place?
>
When you don't have the right tool for the right job, you can either wait
>
until someone gives you the tool you need, or you can create you're own
>
and get to work.
Did I mention excellente extensibilitye as being the prime requirement for
AS? It satisfies this requirement without the need to add a multitude of
petty hacks and kludges to the language itself. Any time you need to do
something AS can't do, you drop into another language that can and do it
there.
Look... there is absoulely _zero_ chance in hell that AS will _ever_
natively do everything that everyone wants it to. It's a fool's errand for
the AS engineers even to try: as soon as one demand is met, a dozen new
ones appear in its place. The next best, and only realistic, solution is to
make it easy - REALLY easy - to let other languages do all this work for
it. Sometimes C, sometimes Perl, sometimes shell scripts... Java, Obj-C,
Python; perhaps even functional and declarative languages [which, despite
OS X's ongoing accumulation of 3rd-parties, are still noticeable by their
absence].
Language extensions allow you to create the tools you need, for yourself,
by yourself. Create an environment where it's stupidly simple to whack out
a dozen lines of Python or C and hook it into AppleScript, and you've got
your solution right there. All that's really missing is the framework for
hooking such code into AppleScript without having to jump through a
multitude of hoops first.
Goode cheeres,
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.