I'm looking for a bit of help. I can't seem to get the block to "pass
through" to the parent class. I figured without an '&' in the parameter
list there would be no conversion to proc but maybe that is not the
case.
class Nstring < String
def gsub!(*args)
super
end
end
This works as I expected:
s = Nstring.new("hi")
s.gsub!(/(hi)/,'\1')
=> "hi"
irb(main):023:0> class NString < String
irb(main):024:1> def gsub!(*args, &blk)
irb(main):025:2> super(*args, &blk)
irb(main):026:2> end
irb(main):027:1> end
=> nil
irb(main):028:0> s = NString.new("hi")
=> "hi"
irb(main):029:0> s.gsub!(/(hi)/){$1}
=> "hi"
Hope this helps,
Jesus.
···
On Thu, Jul 31, 2008 at 11:06 AM, Lou Zell <lzell11@gmail.com> wrote:
Hi all,
I'm looking for a bit of help. I can't seem to get the block to "pass
through" to the parent class. I figured without an '&' in the parameter
list there would be no conversion to proc but maybe that is not the
case.
class Nstring < String
def gsub!(*args)
super
end
end
This works as I expected:
s = Nstring.new("hi")
s.gsub!(/(hi)/,'\1')
=> "hi"
Here is the final solution
class NString < String
def initialize str
replace str
end
def gsub! *args
super( *args, &Proc::new ) # that is just to show you yet another
way to do this but passing &blk is better
end
end
n = Nstring::new( "123")
p n
p n.gsub!(/.../){ |m| m.reverse } # $1 is not set as somebody did
point out already
HTH
Robert
···
On Thu, Jul 31, 2008 at 7:10 PM, Lou Zell <lzell11@gmail.com> wrote:
Sorry, it seems that my $1 was set by previous tests in IRB
The others are right and the discussion has been interesting.
It also shows you have to be careful with tests in IRB...
Jesus.
···
On Thu, Jul 31, 2008 at 7:10 PM, Lou Zell <lzell11@gmail.com> wrote:
Hi,
This worked for me:
irb(main):023:0> class NString < String
irb(main):024:1> def gsub!(*args, &blk)
irb(main):025:2> super(*args, &blk)
irb(main):026:2> end
irb(main):027:1> end
=> nil
irb(main):028:0> s = NString.new("hi")
=> "hi"
irb(main):029:0> s.gsub!(/(hi)/){$1}
=> "hi"
Hope this helps,
Jesus.
Hi Jesus, thank you for your response. Unfortunately, I could not
replicate your results:
I know that and I still managed to screw up my String subclass
constructor :-(. But I agree, interesting thread, always
good to refresh some "basic" things.
Cheers
Robert
···
On Fri, Aug 1, 2008 at 7:54 AM, Jesús Gabriel y Galán <jgabrielygalan@gmail.com> wrote:
Sorry, it seems that my $1 was set by previous tests in IRB
The others are right and the discussion has been interesting.
It also shows you have to be careful with tests in IRB...
That having been said, I generally avoid sub-classing core Ruby
objects because I think some of them use optimizations that cause
internal C methods to be called rather than the methods of a subclass,
resulting in strange behaviour. That having been said, I don't know
that I've ever seen it in practice. Does anyone have an example of
this, or am I just being paranoid?
-greg
···
On Thu, Jul 31, 2008 at 1:47 PM, Lou Zell <lzell11@gmail.com> wrote: