Re: Producing Unicode-only characters [was: Finding \t, \r, \n reliably]
Re: Producing Unicode-only characters [was: Finding \t, \r, \n reliably]
- Subject: Re: Producing Unicode-only characters [was: Finding \t, \r, \n reliably]
- From: Emmanuel <email@hidden>
- Date: Wed, 26 Oct 2005 15:47:34 +0200
At 8:17 PM +1000 10/26/05, Shane Stanley wrote:
On 26/10/05 6:53 PM, "Emmanuel" <email@hidden> wrote:
Shane, it's a pity you can't afford using Smile. You would waste less
time asking (pleading?) for new built-in features.
It's a reality when dealing with clients. Some make it difficult to do --
the letters "SOE" seem to have taken on some magical significance -- and
others, well, when trouble-shooting remotely, I just like to keep the number
of potential variables to the absolute minimum. People move stuff between
machines, and so on.
This can probably be discussed, situations where clients equipped
with a Smile-based system are supported remotely do occur. That said,
the new features in Smile 3.1 will probably provide a better reason
to make the leap.
There's also a responsibility angle. If a client's script fails because
Apple broke something, or Adobe or Quark or whatever, I can explain that
(well, sort of). But if it's a third-party item, it gets more complicated.
Suppose it is one of has's libraries: I can't very well tell him to fix it
pronto, and that sort of thing can be hard to explain to an irate client.
I've depended on third-party items before, and been bitten.
Certainly. That's why all of us providers of free AppleScript
software more or less explicitly offer a deal in terms of: "If you
want to be sure, program yourself your commands in XCode, and test
yourself your own stuff. But you may prefer joining thousands of kind
testers of what we program, and test before you ship: we will be glad
to fix very rapidly whatever bug you find - it's just what we want,
improving our products."
> Logically, you should not too often ask the AppleScript team to
implement a new feature that a third-party programmer could implement.
If they follow your suggestion, they will take on the time they would
otherwise spend on the issues that no-one can program for them, so
your suggestion will slow down the improvements of the language.
I take your point, but I think this case is a bit different: Apple already
has ASCII number and ASCII character commands, but it has now deprecated
plain text in favor of Unicode text. I see it really as a case of making
those existing tools Unicode-compliant, like they have with most (all?) the
other standard additions. If that's unreasonable, I'd prefer that the
existing ones at least produced an error with out-of-range items.
It's natural to want that ASCII number/character be adapted. My point
is that it would be still better if Apple spent their time improving
their engine.
> One of the powerful ideas in AppleScript is that Apple program a core
not too heavy to maintain, and since it's a communication language
third-party programmers provide the commands that users need. I would
think that as a user who appreciates AppleScript you should share and
even favor this vision.
Honestly, I do and I don't. I think a certain level of basic text tools
should be provided, and this is especially so with the transition to
Unicode.
This makes a good reason only inasmuch the previous points are
granted. Otherwise, you should let Apple make the engine and you
would rely even for basic things on the third-party additions - that
you would have contributed to perfect. Finally a Scripting addition
such as has makes would be more reliable and more powerful in less
time, and on its side the engine would improve more rapidly.
If you prefer, there is no perfect solution, but you're pushing the wrong guy.
But I have a plane to catch in the morning, and I shouldn't be here...
That's what happens to people whose country is a continent, I suppose
... have a safe flight.
Emmanuel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden