Prev: Installing Ruby 1.9.2 on Win7
Next: IO.popen
From: James Harrison on 2 Aug 2010 09:54
If you're going to write an email and be wrong, be wrong on every point, that's what I was always taught and I'm sticking by it goddamit!

On Aug 2, 2010, at 7:28 AM 8/2/10, Brian Candler wrote:

> James Harrison wrote:
>> The symbolic constant for truth is True, not true.
>
> That is incorrect, as 5 seconds with irb will show you.
>
> $ irb --simple-prompt
>>> true
> => true
>>> True
> NameError: uninitialized constant True
> from (irb):2
>
> (You may have been thinking of TrueClass and FalseClass, perhaps?)

You're 100% correct. Total brainfart.


>
>> In either case, because File.file? returns either True or False, you can
>> drop the comparison:
>
> It returns true or false, but yes the comparison can be removed.


>
>> If this is truly a method in an object, though, bear in mind scoping
>> issues. pwdFiles is only available inside this method definition. When
>> you declare it in your intialize statement, prepend with a
>> scope-changing symbol. The most common in this case is @
>>
>> def initialize
>> #will contain all file entries in the directory
>> @pwdFiles = []
>> end
>
> @ is not a "scope changing symbol". @pwdFiles is an instance variable of
> the object, whereas pwdFiles is a local variable. They are completely
> different concepts.
>
> Since the OP wanted to return the value from the getFiles method, and
> not set any instance variables in the object, then a local variable is
> appropriate here.



In future, I'll have to stop myself whenever the thought "that mightn't be the right word" crops through my head. I figured it'd be close enough to get the idea across, but given that a symbol is actually a language construct I should've taken a few more seconds out.


In either case, you've hit something that interests me. Conceptually, I'd understood that the difference between an @-prepended variable and a non-@-prepended variable is that the former is global to the object, so it's not impacted by the change in scope introduced by defining a method inside the object. So I figured that describing the @ character as changing the internal scope of a variable from local to global inside the object wouldn't be entirely missing the mark. But it's possible I'm missing something.


Thanks for the clarifications and corrections, dude.

Best

James


From: Brian Candler on 2 Aug 2010 10:15
James Harrison wrote:
> In either case, you've hit something that interests me. Conceptually,
> I'd understood that the difference between an @-prepended variable and a
> non-@-prepended variable is that the former is global to the object, so
> it's not impacted by the change in scope introduced by defining a method
> inside the object. So I figured that describing the @ character as
> changing the internal scope of a variable from local to global inside
> the object wouldn't be entirely missing the mark. But it's possible I'm
> missing something.

They are different in both scope and lifetime.

Instance variables (@foo) are a property of the object instance itself,
and once set, they remain for as long as the object exists, or until
reassigned. Calls to methods of the same object will see the same value
of @foo - even multiple concurrent calls in different threads.

Local variables are created in an activation record which is created
when the method is invoked, and so the values are not tied to the object
itself. If there are multiple calls to the method from multiple threads,
they will have their own activation records, and so independent local
variables. Normally the activation record is garbage-collected when the
method returns.

Now, I'm not sure I should be complicating things here, but activation
records may have extended lifetimes too, when closures are involved.

class Foo
def initialize(n)
@n = n
end
def make_adder(y)
lambda { |x| y + x }
end
end

f = Foo.new(1) # #<Foo @n=1>

a1 = f.make_adder(10)
a2 = f.make_adder(20)
a1.call(3) # 13
a1.call(4) # 14
a2.call(5) # 25

y is a local variable in make_adder, but it persists in the lambdas,
even after make_adder has returned. The two lambdas, a1 and a2, have
different values bound to y. But there is still only a single object of
class Foo.

My apologies if this has confused matters further :-) But hopefully it
highlights how different these things are.

Regards,

Brian.
--
Posted via http://www.ruby-forum.com/.

From: Marvin Gülker on 2 Aug 2010 10:01
Kyle Barbour wrote:
> def getFiles(dir)
> pwdFiles = Array.new
>
> Dir.foreach(dir) do |entry|
> pwdFiles.push(entry) if File.file?(entry) == true
> end
> end

That can't work since Dir.foreach yields only the filenames of the files
in the directory to the block, not the directory the files are actually
in. So suppose you have:

dir/my_file
dir/my_second_file

By calling Dir.foreach("dir") you'll get "my_file" and "my_second_file".
Your File.file? statement then checks for the presence of the filenames
in the current working directory -- where they don't reside. Solution:
Append "dir" to the filename.

def get_files(dir)
pwd_files = Array.new

Dir.foreach(dir) do |entry|
path = File.join(dir, entry)
pwd_files.push(path) if File.file?(path)
end
pwd_files
end

And please use snake_case for your method and variable names.

Marvin
--
Posted via http://www.ruby-forum.com/.

First  |  Prev  | 
Pages: 1 2
Prev: Installing Ruby 1.9.2 on Win7
Next: IO.popen