Feature #4824

Provide method Kernel#executed?

Added by Lazaridis Ilias almost 3 years ago. Updated over 1 year ago.

[ruby-core:36730]
Status:Assigned
Priority:Normal
Assignee:Yukihiro Matsumoto
Category:core
Target version:next minor

Description

The current construct to execute main code looks not very elegant:

if FILE == $0
my_main() # call any method or execute any code
end

With a Kernel#executed? method, this would become more elegant:

if executed?
#do this
#do that
my_main()
end

or

main() if executed?

This addition would not break any existent behaviour.

History

#1 Updated by Yukihiro Matsumoto almost 3 years ago

I agree providing a method to tell whether it is loaded as a library or is executed as a command is more elegant than 'FILE == $0', but I am still afraid #executed? can mean multiple ways so that the name can cause confusion. We need a better name.

#2 Updated by Cezary Baginski almost 3 years ago

On Sat, Jun 04, 2011 at 11:17:01PM +0900, Yukihiro Matsumoto wrote:

I agree providing a method to tell whether it is loaded as a library
or is executed as a command is more elegant than 'FILE == $0',
but I am still afraid #executed? can mean multiple ways so that the
name can cause confusion. We need a better name.

How about the inverse or something similar:

unless required? # top-level file, not require'd or loaded
#main
puts "hello from main"
end

This would also protect from main being run twice when the file
includes itself.

--
Cezary Baginski

#3 Updated by Stephen Sykes almost 3 years ago

Some other suggestions:

if main?
if firstscript?
if main
script?
if run_script?

-Stephen

On Sat, Jun 4, 2011 at 5:48 PM, Cezary cezary.baginski@gmail.com wrote:

On Sat, Jun 04, 2011 at 11:17:01PM +0900, Yukihiro Matsumoto wrote:

I agree providing a method to tell whether it is loaded as a library
or is executed as a command is more elegant than 'FILE

#4 Updated by Lazaridis Ilias almost 3 years ago

Some notes subjecting the naming:

The clarity of the method name should be rated in it's OO context, like this:

if self.executed? # or .started? .launched?, which means not .included? .required? .loaded?
# do main code
end

similarly, one could write:

unless self.executed?
# do inclusion code
end

"self" would be "the module" or "the file" or "the main object"

Possibly the most simple word would be "main?", but strictly from a OO view, this would be not correct.

Although, from a user view, it looks simple and recognizable:

if main?
do main stuff
end

unless main?
do inclusion stuff
end

In any way, the name should be a compact one, e.g. without "", like isstarted?

#5 Updated by Clifford Heath almost 3 years ago

On 05/06/2011, at 4:01 PM, Lazaridis Ilias wrote:

The clarity of the method name should be rated in it's OO context,

like this:

I dispute the need for a method. That just forces someone to the

documentation
to know what the code means.

The problem with the existing solution "if (FILE == $0)" is that

the meaning is
hidden. If the variables were named differently, this would be exactly

the expression
that would best communicate the intent. To exaggerate, what we need is:

if THIS_FILE == $THIS_PROGRAM
...
end

That is, the problem is that it's not obvious to a newcomer that

FILE means
the current source-code file, or that $0 means the name of the script

being
executed. Especially the latter...

Clifford Heath.

#6 Updated by Benoit Daloze almost 3 years ago

Clifford Heath wrote:

That is, the problem is that it's not obvious to a newcomer that FILE means
the current source-code file, or that $0 means the name of the script

being executed. Especially the latter...

$PROGRAMNAME is an alias for $0.
But "if _
FILE__ == $PROGRAM_NAME" is quite long.

#7 Updated by Clifford Heath almost 3 years ago

On 05/06/2011, at 11:29 PM, Benoit Daloze wrote:

Clifford Heath wrote:

That is, the problem is that it's not obvious to a newcomer that

FILE means
the current source-code file, or that $0 means the name of the script
being executed. Especially the latter...

$PROGRAMNAME is an alias for $0.
But "if _
FILE__ == $PROGRAM_NAME" is quite long.

Length is not a problem, if the text includes the meaning.

Things that are used often should be succinct, and the reader's
knowledge should be assumed. Things that are used only a
few times in a program do not need to be succinct.

To use an API call requires that the user knows (or looks up)
the meaning. This kind of semantic hiding is completely
unnecessary and counter-productive.

Clifford Heath.

#8 Updated by Lazaridis Ilias almost 3 years ago

Clifford Heath wrote:
[...]

But "if FILE == $PROGRAM_NAME" is quite long.
[...]
To use an API call requires that the user knows (or looks up)
the meaning. This kind of semantic hiding is completely
unnecessary and counter-productive.
[...]

So maybe all rarely used methods should be written in long descriptive statements, to overcome non-semantic-hiding and become more productive?

There's one simple fact:

"if FILE == $PROGRAM_NAME" is inconsistent with the language's elegant OO design - and I don't think that anyone will counter this.

And at this point, the "dispute" is about the method name.

Which method name would you choose, if you had two choices (.main? | .executed?) ?

#9 Updated by Clifford Heath almost 3 years ago

On 06/06/2011, at 3:51 PM, Lazaridis Ilias wrote:

So maybe all rarely used methods should be written in long

descriptive statements, to overcome non-semantic-hiding and become

more productive?

I thought you prided yourself on your ability to use reason?
Because the above is really an irrational statement, being
both a logical non-sequitur and unrelated to my argument.

There's one simple fact:
"if FILE == $PROGRAM_NAME" is inconsistent with the language's

elegant OO design

I think that's entirely false.

If I was explaining the intent of my code to you, I'd say
"If we're running this file", or "if this is the file we're running".
These have the same semantic structure as the Ruby code
above... completely unlike the suggestion you make.

And at this point, the "dispute" is about the method name.

No, it isn't. It's about how to make Ruby easier to read.

Which method name would you choose, if you had two choices (.main?

| .executed?) ?

Neither. The meaning that is intended cannot be expressed using the
natural meaning of any single word. If the method was implemented,
I'd still write it out long-hand.

I want to minimise the cognitive load on people who read my code.

Clifford Heath.

#10 Updated by Lazaridis Ilias almost 3 years ago

Clifford Heath wrote:
[...] - omitting, to focus on essence

And at this point, the "dispute" is about the method name.

No, it isn't. It's about how to make Ruby easier to read.

The status of this issue (#4824) is "agreed providing a method" (= provide an OO construct) and more actual "We need a better name." (Source: See the first comment).

So, it's about to make the language easier to read, in context of an OO construct.

I've added some elaborations, subjecting the (OO method) name. Ideally, it would be one word, but it's possible to use something like this:

if thisfileisequalwiththeprogram_name?

Although I dislike a two-word choice, the most logical seems to be this one:

if is_executed? # refers to the actual main object. the user has anyway to learn: there is a "self" behind, an object behind

if self.is_executed? # can be written with "self", to make it more clear

main() if self.is_program?

main() if is_program?

So, the point is, to find a concise method name (ideally one word) which reads nice and fits in the overall existent naming scheme of the language.

(note that I "back-off" from this issue for now)

#11 Updated by Rodrigo Rosenfeld Rosas almost 3 years ago

Ruby allows a question mark in method names exactly for avoiding writing methods beggining with "is_" like in Java. I don't mind two word methods, but I don't want the first word to be a "is" when it is finished with a question mark. That is redundant.

By the way, among suggestions, I prefer either main? or main_script?. Maybe aliases :)

#12 Updated by Charles Nutter almost 3 years ago

On Mon, Jun 6, 2011 at 7:09 AM, Rodrigo Rosenfeld Rosas
rr.rosas@gmail.com wrote:

Issue #4824 has been updated by Rodrigo Rosenfeld Rosas.

Ruby allows a question mark in method names exactly for avoiding writing methods beggining with "is_" like in Java. I don't mind two word methods, but I don't want the first word to be a "is" when it is finished with a question mark. That is redundant.

By the way, among suggestions, I prefer either main? or main_script?. Maybe aliases :)

I like main? as well. But I have a concern: the method would have to
be able to see the caller's context, along the lines of eval. I hate
the idea of adding more methods that can do that.

I might be more inclined to a keyword or pseudo constant along the
lines of FILE, like MAIN that produces true iff FILE ==
$0. Something we can statically determine before runtime without
digging around in the caller's frame.

  • Charlie

#13 Updated by Ryan Davis almost 3 years ago

On Jun 8, 2011, at 00:44 , Charles Oliver Nutter wrote:

I might be more inclined to a keyword or pseudo constant along the
lines of FILE, like MAIN that produces true iff FILE

#14 Updated by Rodrigo Rosenfeld Rosas almost 3 years ago

Em 08-06-2011 06:13, Ryan Davis escreveu:

On Jun 8, 2011, at 00:44 , Charles Oliver Nutter wrote:

I might be more inclined to a keyword or pseudo constant along the
lines of FILE, like MAIN that produces true iff FILE ==
$0. Something we can statically determine before runtime without
digging around in the caller's frame.
While I think the feature request is a bit inane to begin with, I think MAIN is a beautifully pragmatic compromise. Easy to implement on all impls, non-hacky, and yet makes its intention very clear.

I like the idea too. I just think that Ruby is very simple to start with
because it is very consistent and with a few rules. Someone would expect
MAIN to be a constant, which is not. Maybe something like MAIN?
would show the contrast to something that seems to be like a constant
(MAIN) but doesn't seem at the same time (?). I know this is still
confusing, but I prefer something like this instead of a pure __MAIN
...

#15 Updated by Rodrigo Rosenfeld Rosas almost 3 years ago

Actually, maybe something like the snippet below would be ideal:

if defined?(MAIN) ...

This means MAIN is still a constant, but one defined by the interpreter in some conditional way that is injected only in a single file (the main one).

#16 Updated by B Kelly almost 3 years ago

Hi,

Rodrigo Rosenfeld Rosas wrote:

I like the idea too. I just think that Ruby is very simple to start with
because it is very consistent and with a few rules. Someone would expect
MAIN to be a constant, which is not.

Why would one expect MAIN to be any more or less of a
constant than FILE or LINE or method ?

Seems to me its behavior would be consistent with the others.

Regards,

Bill

#17 Updated by Rodrigo Rosenfeld Rosas almost 3 years ago

Em 08-06-2011 08:50, Bill Kelly escreveu:

Why would one expect MAIN to be any more or less of a
constant than FILE or LINE or method ?

Seems to me its behavior would be consistent with the others.

Hi Bill, yes, you're right. I agree with you. I didn't think about this
before :)

#18 Updated by Nobuyoshi Nakada almost 3 years ago

Hi,

At Wed, 8 Jun 2011 16:44:55 +0900,
Charles Oliver Nutter wrote in :

I might be more inclined to a keyword or pseudo constant along the
lines of FILE, like MAIN that produces true iff FILE ==
$0. Something we can statically determine before runtime without
digging around in the caller's frame.

FILE.main?

--
Nobu Nakada

#19 Updated by Rodrigo Rosenfeld Rosas almost 3 years ago

Em 08-06-2011 11:28, Nobuyoshi Nakada escreveu:

Hi,

At Wed, 8 Jun 2011 16:44:55 +0900,
Charles Oliver Nutter wrote in :

I might be more inclined to a keyword or pseudo constant along the
lines of FILE, like MAIN that produces true iff FILE ==
$0. Something we can statically determine before runtime without
digging around in the caller's frame.
FILE.main?

I loved this one!

#20 Updated by Lazaridis Ilias almost 3 years ago

Nobuyoshi Nakada wrote:

Hi,

At Wed, 8 Jun 2011 16:44:55 +0900,
Charles Oliver Nutter wrote in :

I might be more inclined to a keyword or pseudo constant along the
lines of FILE, like MAIN that produces true iff FILE ==
$0. Something we can statically determine before runtime without
digging around in the caller's frame.

@C.O. Nutter
I you dislike "digging around in the caller's frame", then you can possibly implement it in a different way.

FILE.main?

This is not an OO approach, even I would prefer to use "if FILE == $0" instead.

I would expect to see FILE.main? in python, not in ruby.

There is already an object available, accessible via "self".

main? # read: is main?
# do main stuff
end

or

self.main? # read: self is main?
# do main stuff
end

in some way, self refers to the file or code module/object.

#21 Updated by Markus Fischer almost 3 years ago

Hi,

I take the courtesy to hijack this because ...

On 08.06.2011 13:31, Rodrigo Rosenfeld Rosas wrote:

Issue #4824 has been updated by Rodrigo Rosenfeld Rosas.

Actually, maybe something like the snippet below would be ideal:

if defined?(MAIN) ...

This means MAIN is still a constant, but one defined by the interpreter in some conditional way that is injected only in a single file (the main one).

This "injected only in a single file" makes me wonder about one thing:
does Ruby in some way provide a per file context?

I guess those familiar with Python will recognize this immediately, as a
file is treated as a (python) module which has it's on scoping and
provides the ability for others to "import" only certain features of a
module/file you want.

I though it would give a nice addition to Ruby but as I understand it,
it would be quite radical as Ruby has the module keyword already and
things work (quite?) differently.

  • Markus

#22 Updated by Lazaridis Ilias almost 3 years ago

Markus Fischer wrote:

Hi,

I take the courtesy to hijack this because ...
[...]

Hijacking issues on an issue-tracking-system is really not the way to go.

Better open a new issue (or a new discussion topic) and place a link to it, if it's somehow related.

#23 Updated by Lazaridis Ilias almost 3 years ago

Lazaridis Ilias wrote:

Nobuyoshi Nakada wrote:
[...]

FILE.main?

This is not an OO approach, even I would prefer to use "if FILE == $0" instead.

I would expect to see FILE.main? in python, not in ruby.

There is already an object available, accessible via "self".
[...]
self.main? # read: self is main?
# do main stuff
end

in some way, self refers to the file or code module/object.

Correcting myself:

Taking in account that "self" refers to the "main" object (the global object) and not to the file object (as it should, from my point of view), possibly this one could do it:

FILE.executed?

(this could get a related method: FILE.imported? )

Is there anything that disallows usage of "FILE" instead of "FILE"? I personally cannot look at those x things when writing OO (one reason I dropped python).

A convention like: CAPITALS for immutable constant objects (without those __ __)?

#24 Updated by Cezary Baginski almost 3 years ago

This may seem like heresy, but isn't really:

FILE == $0

just a hack for letting a file be both a script and a "library" at the same time? With the only sane use (I can think of) being adding unit tests?

This was probably useful in the early years of Ruby, but now with the internet, social coding, methodologies, TDD, BDD, packaging (gems), etc. - doesn't it make more sense to have tests and scripts in separate files?

Why add a construct for handling a block of code that cannot be called in any other way, than running the script directly, creating dead code that isn't included in coverage?

#25 Updated by Rocky Bernstein almost 3 years ago

Cezary Baginski wrote:

This may seem like heresy, but isn't really:

FILE == $0

just a hack for letting a file be both a script and a "library" at the same time? With the only sane use (I can think of) being adding unit tests?

I wrote my thoughts regarding this to ruby-core on June 5-6. See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/36772. But I realize that doesn't get reflected here in redmine.

It has one answer to your question which, in sum, is "demo code". Demonstration code is not the same as a unit test.

But there is another use. One can write a program that has a command-line interface, but folks can use this as a library instead. For example see, https://github.com/rocky/ps-watcher

This was probably useful in the early years of Ruby, but now with the internet, social coding, methodologies, TDD, BDD, packaging (gems), etc. - doesn't it make more sense to have tests and scripts in separate files?

Why add a construct for handling a block of code that cannot be called in any other way, than running the script directly, creating dead code that isn't included in coverage?

#26 Updated by Jan Lelis almost 3 years ago

I'd still prefer a Kernel method - It's about better readability, isn't it? My favourites:

directly_executed?
standalone?

If it should be some kind of keyword, I can't see any serious issue against the MAIN solution. It's true in the "main" file, false in all others and

if MAIN

looks OK.

#27 Updated by Austin Ziegler almost 3 years ago

On Thu, Jun 9, 2011 at 3:49 PM, Cezary Baginski
cezary.baginski@gmail.com wrote:

Issue #4824 has been updated by Cezary Baginski.
This may seem like heresy, but isn't really:

 FILE

#28 Updated by Cezary Baginski almost 3 years ago

On Fri, Jun 10, 2011 at 07:20:32AM +0900, Rocky Bernstein wrote:

Issue #4824 has been updated by Rocky Bernstein.

Cezary Baginski wrote:

This may seem like heresy, but isn't really:

FILE == $0

just a hack for letting a file be both a script and a "library"
at the same time? With the only sane use (I can think of) being
adding unit tests?

I wrote my thoughts regarding this to ruby-core on June 5-6. See
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/36772.

Yes, I read your comments (I read the list). It was what got me
thinking. I didn't like checking using file path strings either.

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?

But there is another use. One can write a program that has a
command-line interface, but folks can use this as a library instead.
For example see, https://github.com/rocky/ps-watcher

Shouldn't there be an executable script installed in bin/ loading a
lib/ps-watcher/cli.rb file ? It would be accessible from $PATH.
And unit/integration tests can be simpler and more robust.

I understand the use case(s), but I don't see why 'FILE == $0' is
really that useful and good practice enough to be explicitly supported
by the language.

As for the name - anything containing 'main' assumes familiarity with
C-type languages, which may or may not be the case for novices.

--
Cezary Baginski

#29 Updated by Cezary Baginski almost 3 years ago

On Fri, Jun 10, 2011 at 09:35:24PM +0900, Austin Ziegler wrote:

On Thu, Jun 9, 2011 at 3:49 PM, Cezary Baginski
cezary.baginski@gmail.com wrote:

Issue #4824 has been updated by Cezary Baginski.

 FILE == $0

just a hack for letting a file be both a script and a "library"
at the same time? With the only sane use (I can think of) being
adding unit tests?

Tests are most certainly not the only good reason for this feature,
and I would regret its departure.

By "sane" use I didn't mean "good" use. Especially with a team working
together and source control. I have nothing against the current use of
checking for main script, but I don't think promoting its use through
additional language support is beneficial.

--
Cezary Baginski

#30 Updated by Cezary Baginski almost 3 years ago

On Sat, Jun 11, 2011 at 11:20:31AM +0900, Rocky Bernstein wrote:

On Fri, Jun 10, 2011 at 10:03 AM, Cezary cezary.baginski@gmail.com 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.isfive?
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 ismp3? and ishtml? 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

#31 Updated by Cezary Baginski almost 3 years ago

On Tue, Jun 14, 2011 at 03:23:27PM +0900, Rocky Bernstein wrote:

On Mon, Jun 13, 2011 at 9:25 AM, Cezary cezary.baginski@gmail.com 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

#32 Updated by Gregory Brown almost 3 years ago

On Sat, Jun 4, 2011 at 10:17 AM, Yukihiro Matsumoto matz@ruby-lang.org wrote:

Issue #4824 has been updated by Yukihiro Matsumoto.

I agree providing a method to tell whether it is loaded as a library or is executed as a command is more elegant than 'FILE

#33 Updated by Charles Nutter almost 3 years ago

On Wed, Jun 15, 2011 at 4:24 PM, Gregory Brown
gregory.t.brown@gmail.com wrote:

Lastly, I think MAIN is reasonable if a method is not to be used,
though it feels a bit too magic for me.

I'll repeat what others have repeated...more magic than FILE,
LINE, or even $0 itself?

  • Charlie

#34 Updated by Lazaridis Ilias almost 3 years ago

The sentence "defines" essentially the terminology:

Yukihiro Matsumoto wrote:

I agree providing a method to tell whether it is loaded as a library or
^
"is loaded"

loaded?

is executed as a command
^
"is executed"

executed?

is more elegant than 'FILE == $0', but I am still afraid #executed? can mean multiple ways so that the name can cause confusion. We need a better name.

Thus the question to focus on is:

  • is "executed?" not clear enough?

If not, possibly just "loaded?" can be introduced.

main() unless loaded?

#35 Updated by Yusuke Endoh about 2 years ago

  • Status changed from Open to Assigned
  • Assignee set to Yukihiro Matsumoto

#36 Updated by Xavier Noria almost 2 years ago

I vote for MAIN.

I think "main" will resonate to a lot of people with different backgrounds to indicate the entry point of the program, and choosing a keyword instead of a method seems coherent with other keywords like FILE.

#37 Updated by Yusuke Endoh over 1 year ago

  • Target version set to next minor

Also available in: Atom PDF