[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 <[e-mail]> 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