I noticed that a lot of scripts apply the following coding pattern:
if __FILE__ == $0
....
end
I know what is does but what kind of problems does it solve?
thx,
used-to-be-a-Smalltalker
I noticed that a lot of scripts apply the following coding pattern:
if __FILE__ == $0
....
end
I know what is does but what kind of problems does it solve?
thx,
used-to-be-a-Smalltalker
It allows the file to be both a library (when required the if statement will not run) and executable.
Hope that helps.
James Edward Gray II
On Feb 21, 2006, at 8:58 AM, raving_ruby_rider wrote:
I noticed that a lot of scripts apply the following coding pattern:
if __FILE__ == $0
....
endI know what is does but what kind of problems does it solve?
You will see this sort of thing in other scripting languages. __FILE__ contains the name of the file source file and $0 is the name of the currently executing script. So a file called hello.rb
class Hello
def initialize(name)
@name = name
end
def greet
puts "Hello #{@name}"
end
end
if __FILE__ == $0 then
h = Hello.new('World')
h.greet
end
you can then run this file with ruby hello.rb which will run the code at the bottom. However with tom.rb
require 'hello'
h = Hello.new('tom')
h.greet
when you run tom.rb the __FILE__ == $0 part of hello does not run as the file hello.rb but the currently executing script is tom.rb. This allows you to have a ruby file hold the class for inclusion by other scripts and also be a utility script in it's own right.
Peter Hickman wrote:
You will see this sort of thing in other scripting languages. __FILE__ contains the name of the file source file and $0 is the name of the currently executing script. So a file called hello.rb
...
when you run tom.rb the __FILE__ == $0 part of hello does not run as the file hello.rb but the currently executing script is tom.rb. This allows you to have a ruby file hold the class for inclusion by other scripts and also be a utility script in it's own right.
Not to mention the fact that it allows you to easily write unit tests for most of the code in a script.
V.-
--
http://www.braveworld.net/riva
____________________________________________________________________
http://www.freemail.gr - äùñåÃà õðçñåóÃá çëåêôñïÃéêïý ôá÷õäñïìåÃïõ.
http://www.freemail.gr - free email service for the Greek-speaking.
Dňa Utorok 21 Február 2006 20:25 Damphyr napísal:
Peter Hickman wrote:
> You will see this sort of thing in other scripting languages. __FILE__
> contains the name of the file source file and $0 is the name of the
> currently executing script. So a file called hello.rb...
> when you run tom.rb the __FILE__ == $0 part of hello does not run as the
> file hello.rb but the currently executing script is tom.rb. This allows
> you to have a ruby file hold the class for inclusion by other scripts
> and also be a utility script in it's own right.Not to mention the fact that it allows you to easily write unit tests
for most of the code in a script.
Which I personally can't bear the sight of. Library is script is test? Nuh-uh.
Just my two cents.
David Vallner
So what is the 'ruby way' to store your unit tests? A separate require'd file?
On 2/21/06, David Vallner <david@vallner.net> wrote:
Which I personally can't bear the sight of. Library is script is test? Nuh-uh.
David Vallner wrote:
DÅa Utorok 21 Február 2006 20:25 Damphyr napÃsal:
Peter Hickman wrote:
You will see this sort of thing in other scripting languages. __FILE__
contains the name of the file source file and $0 is the name of the
currently executing script. So a file called hello.rb...
when you run tom.rb the __FILE__ == $0 part of hello does not run as the
file hello.rb but the currently executing script is tom.rb. This allows
you to have a ruby file hold the class for inclusion by other scripts
and also be a utility script in it's own right.Not to mention the fact that it allows you to easily write unit tests
for most of the code in a script.Which I personally can't bear the sight of. Library is script is test? Nuh-uh. Just my two cents.
Well I actually put the unit tests in a different file.
The if $0==__FILE__ check allows me to require the script in the unit test file.
Following mostly the DRY principle and having a knack for organizing code allows you to group most of the functionality in objects (at which point you put them in a 'library' file and forget about it) or methods to be used by the 'top-level' script. Requiring the 'script' file allows me to unit test the methods without contriving manual tests.
I found it most valuable when I do parameter parsing and parameter/configuration validation in my command line scripts.
Cheers,
V.-
--
http://www.braveworld.net/riva
____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.
Adam Shelly wrote:
So what is the 'ruby way' to store your unit tests? A separate
require'd file?
Well, going by the Pickaxe book you end up with something like this:
./classfilename
->/doc
->/lib
->/test
in ./classfilename/lib you create your ruby source file classfilename.rb
in ./classfilename/test you create your ruby test/unit file
classfilename_tc.rb
In classfilename_tc.rb you put the following lines at the start:
#----------------------------------------------------------------
# The following prefixes ../lib to the active ruby load path
$:.unshift File.join(File.dirname(__FILE__), "..", "lib")
require 'test/unit'
require 'classfilename'
class Test_ClassFileName < Test::Unit::TestCase
...
#----------------------------------------------------------------
and then write your test cases as methods. When you run your test suite
you can invoke it from any palce on the system as the #unshift prefixes
the load path with the relative location of the classfilename.rb with
respect to the test case file.
Thus, assuming that for the example given above that ./ = ~/ruby then:
#ruby -w ~/ruby/classfilename/test/classfilename_tc.rb
will work whatever pwd you are in.
I love test/unit...
Regards,
Jim
--
Posted via http://www.ruby-forum.com/\.