• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Removing characters from a string
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing characters from a string


  • Subject: Re: Removing characters from a string
  • From: "Daniel A. Shockley" <email@hidden>
  • Date: Tue, 5 Nov 2002 11:05:37 -0500

Just weighing in on the issue of doing things you didn't explicitly mean to do. John, there's nothing new about the idea that a function should never have unnecessary side-effects. That's been a fundamental rule of good programming for decades. Ridicule of good programming habits doesn't help anyone. If I write a handler called simpleReplace that takes three parameters: source text, what-to-find, and what-to-replace-with, that handler darn well better put back the text item delimiters to what they were, not what the default is. Does the name "simpleReplace" imply to anyone reasonable that "Oh, I'm going to change the TIDs, too - good luck, sucker!"

This isn't a problem for a one-off 10 line script. But, if I'm working on some text, using the TIDs, and I want to do a simpleReplace, I shouldn't have to set the TIDs back to what I want them to be after calling simpleReplace.

Also, you admit that leaving them in some non-default or unexpected state only affects the current session of your script editor. Do you mean to tell me you close your script editor after every time your run a script? I leave Smile and Script Editor both running all the time, and I don't waste my time trying to remember if I need to reset the TIDs before I use them. This is just an extensions of the "If you took it out, put it back. If you opened it, close it." rule that is taught to children.

Taking the risk of causing major annoyances to your own future programs is one thing, but advocating something is another. I'd be very unhappy if I used code someone made available, and it changed the TIDs without telling me, left them with some strange value, or EVEN if it set them to {""}. Again, because I may have had them set to something else for a good reason.

Anyway, I hope you don't think of this as a mean note. It's just something that I feel is important for good programming etiquette, both for ease of programming for oneself, and especially important when one might be writing code to be used by others. A handler designed to move some files shouldn't change the name of my hard-drive to "Macintosh HD" (the old default), and a handler designed to work on text shouldn't change the TIDs without putting them back.

John Delacour wrote:
At 11:29 am +0100 5/11/02, christian vick wrote:

> I don't think we differ on the issue of using TIDs, Paul. I agree
that, if a
script uses TIDs, it should leave them as it finds them.

What means "as it finds them"? Every script has it's own TIDs, so if you
know what your script is doing it shouldn't be a problem!??

Quite so! And the default is {""} and that's the best way to leave
them -- always. So long as when a script exits or terminates the
delimiters are reset to the default, there should never be any
problem within a session.

A changer in Smile will not affect Script Editor and
vice versa.

JD

--
----
Daniel A. Shockley
email@hidden
email@hidden
http://www.danshockley.com
_______________________________________________
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.

  • Follow-Ups:
    • Re: Removing characters from a string
      • From: John Delacour <email@hidden>
  • Prev by Date: Re: URL Access: Limit on URL Length?
  • Next by Date: Scripting FMP in OS X??
  • Previous by thread: Re: Removing characters from a string
  • Next by thread: Re: Removing characters from a string
  • Index(es):
    • Date
    • Thread