From: Lloyd Zusman Date: 2004-08-02T20:41:50+09:00 Subject: Re: Forward references? "Robert Klemme" writes: > "Lloyd Zusman" schrieb im Newsbeitrag > news:m3vfg2tsvl.fsf@asfast.com... >> >> [ ... ] >> >> Sync_m has been around ever since 1.6.x, and it's excplicitly mentioned >> in the Pickaxe book (on page 120, the last line of the "Condition >> Variables" section of Chapter 11, "Threads and Processes"). You can see >> the code in RUBYINSTALLDIR/lib/sync.rb > > Oh, once again learned something new. But as far as I can see it's only > mentioned at this single location - no examples no additional > explanations. Yes, sync.rb (containing Sync_m and Synchronizer_m) is not mentioned or documented anywhere else that I can find. I'm not sure where I stumbled upon it ... I probably saw it used in someone else's code and then investigated it. Although the mutex and monitor classes also can work here, I prefer Sync_m in this case because its name reflects the exact use to which I am putting it: synchronization. > [ ... ] > > Yeah, but you'll soon recognize that the program does not exit. While > it's more difficult ro recognize that it exits in both cases but you > wanted it to do something else in once case IMHO. Maybe it's a matter of > taste or my usage to Eclipse's excellent Java support which gives you > compile error messages and warnings that help a lot. Of course, Ruby is > not compiled... :-) > >> If I want to do something other than exiting, then I can do the >> following with my construct: >> >> # at the bottom of the script ... >> begin >> result = rtail >> rescue Exception => e >> $stderr.puts("!!! #{e}") >> result = 1 >> end >> ###exit(result) >> do_something_other_than_exiting(result) > > Yeah, but that treats both cases (ok and error) the same and you have to > make a distinction in do_something_other_than_exiting(). That's typically > bad; it's better to have separate methods that handle each case > individually because methods then do just *one* thing and not two. Of > course, if you do the same in every case it's reasonable to have a single > method. Yes. Here I always want to exit. If I wanted to do something different on exit and on error, I would structure this code snippet differently. >> [ ... ] >> >> Yes, I often do that. It just seems like overkill in my small app. > > Personally I prefer that kind of "overkill" over other strategies. Adding a number of small methods would decrease maintainability of my particular program, IMO. That is not true in general, and I indeed do this on other kinds of projects. However, think that it does apply in this case. But there is plenty of room to differ here. I refactored the code even more, based on our discussions and some ideas of my own. If you're interested, I can privately email you the latest version. -- Lloyd Zusman ljz@asfast.com God bless you.