Btw, thanks in advance for any help - this community seems great!
I'm using the following line to try to remove objects from an array that
begin with .
_array.each{|item| item.gsub(/^[\.][.]*/){|match|
_array.delete(match)}}
and although the match is functioning properly, the _array still
contains the values after being deleted. I've wondered if
Array.delete("param") actually returns the resulting array but that
doesnt seem to be the case. How do I go about actually altering the
state of the current array if the above is not done correctly?
On Jun 17, 2008, at 6:38 PM, Chance Dinkins wrote:
Btw, thanks in advance for any help - this community seems great!
I'm using the following line to try to remove objects from an array that
begin with .
_array.each{|item| item.gsub(/^[\.][.]*/){|match|
_array.delete(match)}}
and although the match is functioning properly, the _array still
contains the values after being deleted. I've wondered if
Array.delete("param") actually returns the resulting array but that
doesnt seem to be the case. How do I go about actually altering the
state of the current array if the above is not done correctly?
I don't think there's an in place editor for delete_if, so you'd want
_array = _array.delete_if {|x| x.match(/^\./)}
delete_if operates on the array in place:
irb(main):001:0> a = [1,2,3]
=> [1, 2, 3]
irb(main):002:0> a.delete_if {|e| e == 1 }
=> [2, 3]
irb(main):003:0> a
=> [2, 3]
David
···
On Wed, 18 Jun 2008, Teleolurian wrote:
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS June 16-19 Berlin
ADVANCING WITH RAILS July 21-24 Edison, NJ
See http://www.rubypal.com for details and updates!
they are normal functions but one's which take anonymous functions (blocks) as arguments. ruby makes this very easy on the eyes, but even C has this concept: do a 'man qsort' and you'll see
note the 'compar' function you can pass in. so, in c, you have to define that function up front and then pass a pointer to it. in ruby you can do things like
compar = lambda{|a,b| a <=> b}
array.qsort &compar
or, more compactly
array.qsort{|a,b| a <=> b}
of course the method is called 'sort' and not 'qsort', but the principle is exactly the same.
Thanks guys, I apperciate it - these.. dynamic methods (is that what
they are considered?) are a little strange to me.
The methods that expect a code block as part of the method call are
iterators. Basically the code block is a piece of executable code that
you're making available to be called from the method itself.
Typically, that means that a method will fire the code block once for
each element in a collection object like an array.
David
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS June 16-19 Berlin
ADVANCING WITH RAILS July 21-24 Edison, NJ
See http://www.rubypal.com for details and updates!
Thanks guys, I apperciate it - these.. dynamic methods (is that what
they are considered?) are a little strange to me.
they are normal functions but one's which take anonymous functions (blocks) as arguments. ruby makes this very easy on the eyes, but even C has this concept: do a 'man qsort' and you'll see
note the 'compar' function you can pass in. so, in c, you have to define that function up front and then pass a pointer to it. in ruby you can do things like
compar = lambda{|a,b| a <=> b}
array.qsort &compar
or, more compactly
array.qsort{|a,b| a <=> b}
of course the method is called 'sort' and not 'qsort', but the principle is exactly the same.
I'd leave room, though, for the fact that in Ruby, you can provide a
code block to a method, as part of the syntax of the method call, but
you can also send anonymous functions in the argument list. So there's
a sense of "The Block", so to speak, separate from any functions you
might include as regular arguments. (Yes, I do know about the &block
idiom in method signatures
David
···
On Wed, 18 Jun 2008, ara.t.howard wrote:
On Jun 17, 2008, at 9:46 PM, Chance Dinkins wrote:
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS June 16-19 Berlin
ADVANCING WITH RAILS July 21-24 Edison, NJ
See http://www.rubypal.com for details and updates!
Yes, but not in all cases. The presence of the block does not tell
you anything about the frequency of invocation. Just think about
File.open for example. So I'd say the general statement "The methods
that expect a code block as part of the method call are iterators" is
misleading.
Kind regards
robert
···
On 18 Jun., 08:35, "David A. Black" <dbl...@rubypal.com> wrote:
On Wed, 18 Jun 2008, Chance Dinkins wrote:
> Thanks guys, I apperciate it - these.. dynamic methods (is that what
> they are considered?) are a little strange to me.
The methods that expect a code block as part of the method call are
iterators. Basically the code block is a piece of executable code that
you're making available to be called from the method itself.
Typically, that means that a method will fire the code block once for
each element in a collection object like an array.
On 18 Jun., 08:35, "David A. Black" <dbl...@rubypal.com> wrote:
On Wed, 18 Jun 2008, Chance Dinkins wrote:
Thanks guys, I apperciate it - these.. dynamic methods (is that what
they are considered?) are a little strange to me.
The methods that expect a code block as part of the method call are
iterators. Basically the code block is a piece of executable code that
you're making available to be called from the method itself.
Typically, that means that a method will fire the code block once for
each element in a collection object like an array.
Yes, but not in all cases. The presence of the block does not tell
you anything about the frequency of invocation. Just think about
File.open for example. So I'd say the general statement "The methods
that expect a code block as part of the method call are iterators" is
misleading.
I said "typically" One lesson at a time....
David
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS June 16-19 Berlin
ADVANCING WITH RAILS July 21-24 Edison, NJ
See http://www.rubypal.com for details and updates!
