From: Cezary Date: 2011-06-14T20:02:15+09:00 Subject: [ruby-core:37135] Re: [Ruby 1.9 - Feature #4824] Provide method Kernel#executed? On Tue, Jun 14, 2011 at 03:23:27PM +0900, Rocky Bernstein wrote: > On Mon, Jun 13, 2011 at 9:25 AM, Cezary wrote: > > > So why not just use the following in such programs: > > > > def main?; __FILE__ == $0; end # for 'if main?' > > Simplicity and unreliability. My first reaction is usually: is it valuable? Simple != valuable. I think it is reliable enough for the cases mentioned. If reliability is an important issue here, then the implementation is more important than the name anyway. Unless the name is just a starting point for considering the issue at all. Why not start with a gem first? Like Object#me (which became #tap) or #andand which IMHO is much more valuable but would greatly benefit from parser support in Ruby. If simplicity is the main criteria, we could end up with Ruby's namespace exploding with "simplifying" methods that almost no one will use for various reasons. Why not create a 'main' gem and work on getting #andand (#._?) support in Ruby's parser instead? #tap turned out awesome IMHO. I don't see #main? as revolutionary. > Everything you suggest, adds more code. I want less boilerplate code in > fewer files. That is what I meant by "lightweight". Modularity and more code-sharing friendliness is more important. The ps-watcher project seems to reflect this - it contains more than one file, tests separate, Rakefile, functionality split up into small *.rb files, etc. If you like, I can spend some time to see what ps-watcher would like without the 'main' check. Not as a criticism, just as a way to support my point regarding design. I think it would be great to first have a 'main' gem until the implementation matures. And it could be used in older Ruby applications immediately. Like #tap, #andand, etc. > Early on in the thread, Matz had said he was amenable to the idea of adding > a method. But he was unsure about the name. If he had indicated he wasn't > interested, I would have dropped the topic and never have posted a response > initially. Exactly! But I'm still not convinced about the value of such a method. I know I'm dumb, but I don't think I'm dumb enough to not understand a simple, valuable use case where a method is really an improvement worth adding and backporting. Or why wasn't this ticket immediately rejected. Initially, I assumed I'm an idiot and believed the experts on this list saw the value, which I couldn't. Being interested in improving my skills, I got curious to learn what I am not seeing. There is so much functionality that doesn't belong in Ruby core that is way more valuable. How did this get anything else than "rejected"? My only guess is unfortunate popularity of a use case that in itself suggests bad design - which is why an alarm in my head went off. > In my first post which you said I read, I also discussed why the idiom is > unreliable. Yes, and I can imagine it being a problem fixable with a well thought out implementation. It is good you brought it up. I just don't see why improving the reliability of such a minor issue (IMHO) is really productive and worth any other reaction than rejecting or at least suggesting a new gem first. Sorry for prolonging this discussion - I believe it may be worth learning to deal with this issue (or even just people like me) and preventing a whole class of similar cases (discussions?) in the future. If my issues are pointless - let me know and I'll put in more trust in faith in the experts reading on ruby-core and give up on trying to change the way I think. Thanks! -- Cezary Baginski