[ruby-core:37089] Re: [Ruby 1.9 - Feature #4824] Provide method Kernel#executed?

On Sat, Jun 11, 2011 at 11:20:31AM +0900, Rocky Bernstein wrote:
> On Fri, Jun 10, 2011 at 10:03 AM, Cezary <[e-mail]> wrote:
> > On Fri, Jun 10, 2011 at 07:20:32AM +0900, Rocky Bernstein wrote:
> >
> > > It has one answer to your question which, in sum, is "demo code".
> > > Demonstration code is not the same as a unit test.
> >
> > Yes, but shouldn't that be in a README or example.rb instead?
>
> I prefer demo code to be runable in the same way that tests are runable. And
> for simple things, one file is better, feels more lightweight, and is less
> clumsy (...)

So why not instead check for specific script arguments, like '--demo',
'--test', '--help', etc.? If checking for '__FILE__ == $0' is really
the best solution in a given case, my question is: why provide a
special method for the same thing?

> I think we can tolerate different styles, no?

Absolutely! So why not just use the following in such programs:

  def main?; __FILE__ == $0; end      # for 'if main?'

  class String; def main?; self == $0; end; end  #for '__FILE__.main?'

That way, anyone can use their own style for the idiom with little
coding overhead. And it will work with any Ruby version out there.

> > It would be accessible from $PATH.
> > And unit/integration tests can be simpler and more robust.
>
> If you looked at the project, you'll see that there are tests. I don't see
> how unit/integration tests would be made simpler by putting the trivial
> command-line interface, or main() routine, in another file.

Regarding the ps-watcher project specifically, it requires other
project files anyway, so you cannot use the file standalone. So, in
that case, you can assume most of the code (demo?) can be moved to
other files, leaving only the "main" code, after which the '__FILE__'
check around it can be removed altogether.

There is no README file, so it is a little hard to figure out how to
use the application, without reading through everything. Replacing the
"main checking" with a new Ruby 1.9.3 method (that would do the same) is
something I find not worth the time to even discuss.

As for tests - there already is a Rakefile which runs them. Why not
add a 'demo' task there as well?

I'm not trying to criticize the project here - I just don't see it as
a convincing example showing how a new method for the idiom is
valuable.

> Could it just be sufficient to accept that others find it useful
> even if it is not useful to you?

Sure, the idiom is useful, even if I have a hard time thinking of a
case where its use is elegant, the best practice and recommended -
enough to explain the absolute need for anything more that the way it
is done currently (with __FILE__ == $0).

> This is now feels like discussions in Perl when folks would ask if "until"
> was really important enough when there was "if" and "not" And if the form
> with "statement if expression" was really warranted since you had "if
> expression ...".

I get what you are trying to say, but the example isn't a good one
IMHO - keywords are much harder to emulate without language support,
because they affect syntax. Things like Ruby's "unless" are valuable
because of that. __FILE__.main? OTOH is an easy one-liner.

Let me try one: some people mix paint with screwdrivers, because they
have them handy (after opening the paint box). Why would we want to
add "paint mixer" features to *every* screwdriver to support this?

Having a special method for a special case is like having 7.is_five?
or "y".is_yes?. Extreme examples, I know, but why is #main? an
exception here?

> If you feel strongly about such matters, I suppose you could write a new
> programming language or perhaps carve out a subset of Ruby that does not
> have such things that you don't feel are useful or are good practice.

To me this argument is along the lines of: "If you don't like adding
very useful is_mp3? and is_html?  methods to String, why don't you
design your own programming language?".

IMHO, the idiom is not generic enough to deserve its own method.

Actually, it reminds me of discussions about Rails's
HashWithIndifferentAccess. That class handles a specialized case which
is very hard to do otherwise. I understand why it isn't necessary to
support it in Ruby - and I think many will agree, but why in that case
do we need a specialized method to replace code that already does a
job just fine?

I would really like some clear guidelines for proposing and accepting
similar methods in the future.

I don't really care if a method is added or not, I am really
interested in: on what basis was it decided that it is worth
considering?

Ideally, a reason that would be more definite than just a matter of
taste or popularity. And without scrutiny, we may be missing possibly more
sensible options. For example:

  require 'main'

  Main.run do
    puts "Running a demo"
  end

That way we can even call the main manually, handle exit code,
override, etc. Just an idea though.

--
Cezary Baginski