Ideas for replacing $0==__FILE__

[Hal Fulton]

I've accepted now that my "generalized break" was a bad idea. In
an eval context, I'll probably just define a "quit" method that
will throw :quit and that will be fine.

I'm thinking (again) about the idiom "if $0 == __FILE__" and
trying to come up with viable alternatives.

It seems to me that we don't really need an "executable" thing
like exit/break/return/quit in this context.

It could just be a "marker" as someone suggested.

My two favorites so far are __TEST__ and __MAIN__.

As far as I can see, there should be no conflict or interaction
with the __END__ marker.

Comments?

Hal

 

[T. Onoma]

It could just be a "marker" as someone suggested.

My two favorites so far are __TEST__ and __MAIN__.

As far as I can see, there should be no conflict or interaction
with the __END__ marker.

Comments?

Do I understand you correctly, Hal?

sample.rb:

#!/usr/bin/ruby

# ruby code that won't be executed

__MAIN__

# code that will normally be

__TEST__

# will run instead if test (or debug?) flag

__END__

# raw data

 

[Hal Fulton]

Do I understand you correctly, Hal?

Sorry, I was unclear.

It's like this:


#!/usr/bin/ruby
(treat as normal code)
__FOO__
(execute only if this is the main file, not
a required/loaded file)
__END__
(any data)


where FOO is some marker, either MAIN or TEST
or something else.

Better?

Hal

 

[T. Onoma]

#!/usr/bin/ruby
(treat as normal code)
__FOO__
(execute only if this is the main file, not
a required/loaded file)
__END__
(any data)


where FOO is some marker, either MAIN or TEST
or something else.

Better?

So you're just suggesting that __FOO__ be effectively the same as

if $0 == __FILE__
...
end

Yes?

T.

 

[Hal Fulton]

So you're just suggesting that __FOO__ be effectively the same as

if $0 == __FILE__
...
end

Yes?

Yes.

No difference in function, just a little prettier/clearer
and no need to indent or to remember the closing end.

Hal

 

[Eric Hodel]

--dBMBt2YGaTHbdllf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'm thinking (again) about the idiom "if $0 =3D=3D __FILE__" and
trying to come up with viable alternatives.
=20
It seems to me that we don't really need an "executable" thing
like exit/break/return/quit in this context.
=20
It could just be a "marker" as someone suggested.
=20
My two favorites so far are __TEST__ and __MAIN__.
=20
As far as I can see, there should be no conflict or interaction
with the __END__ marker.

We also discussed on IRC having a "-t" flag to the ruby interpreter that
would run a TEST block (like BEGIN or END or at_exit), but __TEST__
seems even better than that.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--dBMBt2YGaTHbdllf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/13t6MypVHHlsnwQRAsILAKCZWuvrHTcx8J46QV34C5XrVaUUxQCg7U+b
Mc5r51OfBQ5soDibUXGXM9k=
=6XQa
-----END PGP SIGNATURE-----

--dBMBt2YGaTHbdllf--

 

[Hal Fulton]

Hal Fulton ([email protected]) wrote:




We also discussed on IRC having a "-t" flag to the ruby interpreter that
would run a TEST block (like BEGIN or END or at_exit), but __TEST__
seems even better than that.

Are we talking about the same thing? In my scheme, if foo.rb had
a __TEST___ section, it would be run simply by ruby foo.rb (and
not run if foo.rb was require'd).

How does that relate to the -t idea (which I don' quite get)?

Hal

 

[T. Onoma]

Are we talking about the same thing? In my scheme, if foo.rb had
a __TEST___ section, it would be run simply by ruby foo.rb (and
not run if foo.rb was require'd).

How does that relate to the -t idea (which I don' quite get)?

Kind of like this idea too. Basically what Eric is suggesting is that if you
have an ruby file like, example.rb:


# normal code here

__SHELL__ # like, if $0 = __FILE__

# shell execution code here

__TEST__

# test code here

__END__

raw data here


If one were to do

% ruby -t example.rb

it would run the code in the __TEST__ seciton rather than the __SHELL__
section.

I can also think of another good section __CGI__

T.

 

[Gavin Sinclair]

I've recently found that it is sometimes useful to combine a "main" Ruby
program with required modules into a single file.

I'm not entirely sure what you mean here. Can we have an example?

[...]

Do people really consider this idiom to be *that* useful? Most of the
times I've seen it used, it wraps either examples (better done in
separate files, you can have more than one and more complex), or tests
(*much* better done with Test::Unit).

I commonly wrap Test::Unit tests in 'if $0 == __FILE__'. It's easier to
edit and execute the tests when they're in the same file. It's less files
in the distribution and no 'how do I include the library in the library
path from the unit test file?' hassles.

Concerning the idiom itself, I initially thought it ugly and pondered the
benefit of a "main" function (i.e. at the top level, def main(*args)).
Having come to appreciate the importance of runtime in Ruby, though, I now
think it is appropriate for programmers to be aware of, and take control
of, what happens when their files are loaded, and in what context.
Therefore I find the idiom aesthetically unappealing but conceptually
acceptable.

Given this, I have little taste for the proposed __MAIN__, __TEST__, etc.
directives.

Gavin

 

[jrb3]

Steve Lumos saith:

$0 == __FILE__ idiom

Do people really consider this idiom to be *that* useful? Most of the
times I've seen it used, it wraps either examples (better done in
separate files, you can have more than one and more complex), or tests
(*much* better done with Test::Unit).

I've found it very useful for my own unit-testing using Test::Unit. Now,
being a Ruby nuby, I haven't absorbed what might have come before about
this, but I set up my unit-testable Ruby library files as executables --
invoke them directly to run the unit tests, and the above idiom guards the
test code.

Others are welcome to point me to current community thought (and working
code on how to do this. This being Ruby not Perl, there should I
guess be only One Way To Do This. ;-)

Joseph Beckenbach
lead XP tester, Eidogen Inc.