[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

define_method, proc with block ?

T. Onoma

10/1/2004 4:09:00 PM

A little help here. I'm trying to dynamically create a method that passes
through to another method but adds in a fixed argument. Unfortunately I can't
pass a block via a proc. How does one handle this? I ended up having to
create two methods for each wrapped method. Yuk. Here's the code snip:

# NOTE: wrap_advice is the method/proc used to wrap meth
# meth is defined in a subclass or singleton, c, to achieve wrapping

# define the interceptor
c.class_eval {
define_method("advice___#{meth}",wrap_advice)
}
c.class_eval %Q{
def #{meth}(*args,&blk)
target = proc{super} #proc{|*args,&blk| super(*args,&blk)}
advice___#{meth}(target,*args,&blk)
end
}

Notice also I can't pass the block via the proc'd super either. I want to just
do this:

# define the interceptor
c.class_eval {
define_method(meth) {|*args,&blk|
target = proc{|*args,&blk| super(*args,&blk)}
wrap_advice.call(target,*args,&blk)
end
}

Any ideas?

Thanks,
T.


6 Answers

Markus

10/1/2004 5:42:00 PM

0

On Fri, 2004-10-01 at 09:08, trans. (T. Onoma) wrote:
> A little help here. I'm trying to dynamically create a method that passes
> through to another method but adds in a fixed argument. Unfortunately I can't
> pass a block via a proc.

Why not? Or more lucidly (asfter this post a swear I'm going for
tea): what problems are you having? It seems like either of the methods
that Mauricio

http://www.talkaboutprogramming.com/group/comp.lang.ruby/messages/1...

or I (about half way down, search for "$observers")

http://www.talkaboutprogramming.com/group/comp.lang.ruby/messages/1...,
suggested on this thread should do the trick.

-- MarkusQ

> How does one handle this? I ended up having to
> create two methods for each wrapped method. Yuk. Here's the code snip:
>
> # NOTE: wrap_advice is the method/proc used to wrap meth
> # meth is defined in a subclass or singleton, c, to achieve wrapping
>
> # define the interceptor
> c.class_eval {
> define_method("advice___#{meth}",wrap_advice)
> }
> c.class_eval %Q{
> def #{meth}(*args,&blk)
> target = proc{super} #proc{|*args,&blk| super(*args,&blk)}
> advice___#{meth}(target,*args,&blk)
> end
> }
>
> Notice also I can't pass the block via the proc'd super either. I want to just
> do this:
>
> # define the interceptor
> c.class_eval {
> define_method(meth) {|*args,&blk|
> target = proc{|*args,&blk| super(*args,&blk)}
> wrap_advice.call(target,*args,&blk)
> end
> }
>
> Any ideas?
>
> Thanks,
> T.



T. Onoma

10/1/2004 6:22:00 PM

0

On Friday 01 October 2004 01:42 pm, Markus wrote:
> On Fri, 2004-10-01 at 09:08, trans. (T. Onoma) wrote:
> > A little help here. I'm trying to dynamically create a method that passes
> > through to another method but adds in a fixed argument. Unfortunately I
> > can't pass a block via a proc.
>
> Why not? Or more lucidly (asfter this post a swear I'm going for
> tea): what problems are you having? It seems like either of the methods
> that Mauricio
>
> http://www.talkaboutprogramming.com/group/comp.lang.ruby/messages...
ml

Ah, thank you. Thank you. Yes, this first example is essentially what I'm
doing. I see from it that block parameters in Procs are taken care of in
1.9+, I just need to update.

> or I (about half way down, search for "$observers")
>
> http://www.talkaboutprogramming.com/group/comp.lang.ruby/messages...
>ml, suggested on this thread should do the trick.

No aliasing for me thanks. But I am curious, is Symbol.uniq new to 1.9?

Thanks Again,
T.


Markus

10/1/2004 7:05:00 PM

0




On Fri, 2004-10-01 at 11:22, trans. (T. Onoma) wrote:
> Ah, thank you. Thank you. Yes, this first example is essentially what I'm
> doing. I see from it that block parameters in Procs are taken care of in
> 1.9+, I just need to update.

Actually, if you &-ize it on the way in you should be fine in 1.8
(at least, it works transparently for me).

> > or I (about half way down, search for "$observers")
> >
> > http://www.talkaboutprogramming.com/group/comp.lang.ruby/messages...
> >ml, suggested on this thread should do the trick.
>
> No aliasing for me thanks. But I am curious, is Symbol.uniq new to 1.9?

Oops. Sorry, it's from my personal bag o'tricks (another ported
lisp-ism):

class Symbol
@@unique_sym_counter = 0
def Symbol.unique(prefix="gloop")
prefix =
prefix.to_s.
gsub(/\+/,'_plus_').
gsub(/\*/,'_times_').
gsub(/-/,'_minus_').
gsub(/\//,'_div_').
gsub(/\!/,'_bang_')
return ("#{prefix.to_s}__#{@@unique_sym_counter += 1}").intern
end
end

So, I'm curious right back: why the aversion to aliasing?

-- MarkusQ




T. Onoma

10/1/2004 7:17:00 PM

0

On Friday 01 October 2004 03:05 pm, Markus wrote:
> So, I'm curious right back: why the aversion to aliasing?

Simple: method namespace clutter.

T.


Markus

10/1/2004 8:06:00 PM

0

On Fri, 2004-10-01 at 12:17, trans. (T. Onoma) wrote:
> On Friday 01 October 2004 03:05 pm, Markus wrote:
> > So, I'm curious right back: why the aversion to aliasing?
>
> Simple: method namespace clutter.

*smile* I used to have that problem with my web browser cache
directory--it kept getting cluttered up with all these files with
cryptic names. It was annoying the tar out of me. Then I decided to
try a trick I'd developed with my mail spool directory: I stopped
looking in there.

That cleared the problem right up.

-- MarkusQ




T. Onoma

10/1/2004 8:21:00 PM

0

On Friday 01 October 2004 04:06 pm, Markus wrote:
> On Fri, 2004-10-01 at 12:17, trans. (T. Onoma) wrote:
> > On Friday 01 October 2004 03:05 pm, Markus wrote:
> > > So, I'm curious right back: why the aversion to aliasing?
> >
> > Simple: method namespace clutter.
>
> *smile* I used to have that problem with my web browser cache
> directory--it kept getting cluttered up with all these files with
> cryptic names. It was annoying the tar out of me. Then I decided to
> try a trick I'd developed with my mail spool directory: I stopped
> looking in there.
>
> That cleared the problem right up.

LOL! :) Yea, well, there is that.

T.