[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

preventing Object#send from dispatching to a global method?

Francis Hwang

5/28/2005 3:43:00 PM

Is there a way to prevent Object#send from dispatching to a global
method? By which I mean:

def something; end

class SomeClass
def method_missing( sym, *args ) .... do magic; end
end

SomeClass.new.something # I'd like this to go to
SomeClass#method_missing, not Kernel#something

I can manage this other ways, but I'd love to use something like send,
if possible.

Francis Hwang
http://f...
16 Answers

Bertram Scharpf

5/28/2005 5:18:00 PM

0

Hi,

Am Sonntag, 29. Mai 2005, 00:42:46 +0900 schrieb Francis Hwang:
> Is there a way to prevent Object#send from dispatching to a global
> method? By which I mean:
>
> def something; end
>
> class SomeClass
> def method_missing( sym, *args ) .... do magic; end
> end
>
> SomeClass.new.something # I'd like this to go to
> SomeClass#method_missing, not Kernel#something

class SomeClass
undef something
end

Probably you thought of no specific method, so one should
remove them all. This causes an error:

class SomeClass
Kernel.methods.each { |x| undef_method x.to_sym }
end

Is there a way to un-include?

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-...

Its Me

5/28/2005 7:47:00 PM

0

Imo, this is a result of global methods becoming methods on the Object
class. If they had been made singleton methods of the "main" object your
method_missing would work as you expect.


"Francis Hwang" <sera@fhwang.net> wrote in message
> Is there a way to prevent Object#send from dispatching to a global
> method? By which I mean:
>
> def something; end
>
> class SomeClass
> def method_missing( sym, *args ) .... do magic; end
> end
>
> SomeClass.new.something # I'd like this to go to
> SomeClass#method_missing, not Kernel#something
>
> I can manage this other ways, but I'd love to use something like send,
> if possible.
>
> Francis Hwang
> http://f...
>
>
>

Francis Hwang

5/29/2005 1:31:00 AM

0

Yeah, that makes sense. I can use that workaround, but the code I'm
looking at is in a library that others might use, and I'd rather not
impose that workaround on others who might accidentally define global
methods that trip over my library's reflection. I wonder if this an
appropriate place for an RCR ... seems to me that with all the Ruby
libs out there that use some intense reflection, somebody else must be
worrying about this? Maybe not.


On May 28, 2005, at 3:50 PM, itsme213 wrote:

> Imo, this is a result of global methods becoming methods on the Object
> class. If they had been made singleton methods of the "main" object
> your
> method_missing would work as you expect.
>
>
> "Francis Hwang" <sera@fhwang.net> wrote in message
>> Is there a way to prevent Object#send from dispatching to a global
>> method? By which I mean:
>>
>> def something; end
>>
>> class SomeClass
>> def method_missing( sym, *args ) .... do magic; end
>> end
>>
>> SomeClass.new.something # I'd like this to go to
>> SomeClass#method_missing, not Kernel#something
>>
>> I can manage this other ways, but I'd love to use something like send,
>> if possible.
>>
>> Francis Hwang
>> http://f...
>>
>>
>>
>
>
>
>

Francis Hwang
http://f...

Jim Weirich

5/29/2005 2:29:00 AM

0


On May 28, 2005, at 11:42 AM, Francis Hwang wrote:

> Is there a way to prevent Object#send from dispatching to a global
> method? By which I mean:
>

You could look at how Builder::BlankSlate handles it. It uses method
defined hooks to undefine any methods added to any ancestors. You
can find BlankSlate in the builder gem.

For example

traken$ irb --simple-prompt
>> require 'builder/blankslate'
=> false
>> class Empty < Builder::BlankSlate
>> def inspect
>> "<empty>"
>> end
>> def method_missing(sym, *args)
>> puts "Calling #{sym}(#{args.join(',')})"
>> end
>> end
=> nil
>> e = Empty.new
=> <empty>
>> e.hi
Calling hi()
=> nil
>> def hi() "HI" end
=> nil
>> e.hi
Calling hi()
=> nil

Francis Hwang

5/29/2005 3:06:00 AM

0

Okay, thanks for the tip, that's definitely giving me some ideas.
Builder::BlankSlate's strategy seems like something for me to follow.
Here's an added piece of complexity: this logic has to depend on values
set during the class definition. I'm talking, BTW, about Lafcadio's
DomainObjects. So:

def fname; "here's an unfortunate coincidence"; end

class User < Lafcadio::DomainObject
text 'fname'
text 'lname'
end

I wanted to trigger some methods to undefine instance methods of
'fname' in User, but I can't do that with Class.inherited -- because at
the time that the User class is being defined, I don't know that I'm
looking for global methods named 'fname' and 'lname'.

It feels like, from perusing the archives, there is currently no way to
be notified when a class definition is finished. Correct?


On May 28, 2005, at 10:29 PM, Jim Weirich wrote:

>
> On May 28, 2005, at 11:42 AM, Francis Hwang wrote:
>
>> Is there a way to prevent Object#send from dispatching to a global
>> method? By which I mean:
>>
>
> You could look at how Builder::BlankSlate handles it. It uses method
> defined hooks to undefine any methods added to any ancestors. You can
> find BlankSlate in the builder gem.
>
> For example
>
> traken$ irb --simple-prompt
> >> require 'builder/blankslate'
> => false
> >> class Empty < Builder::BlankSlate
> >> def inspect
> >> "<empty>"
> >> end
> >> def method_missing(sym, *args)
> >> puts "Calling #{sym}(#{args.join(',')})"
> >> end
> >> end
> => nil
> >> e = Empty.new
> => <empty>
> >> e.hi
> Calling hi()
> => nil
> >> def hi() "HI" end
> => nil
> >> e.hi
> Calling hi()
> => nil
>
>

Francis Hwang
http://f...

Jim Weirich

5/30/2005 12:55:00 AM

0

On Saturday 28 May 2005 11:05 pm, Francis Hwang wrote:
> I wanted to trigger some methods to undefine instance methods of
> 'fname' in User, but I can't do that with Class.inherited -- because at
> the time that the User class is being defined, I don't know that I'm
> looking for global methods named 'fname' and 'lname'.
>
> It feels like, from perusing the archives, there is currently no way to
> be notified when a class definition is finished. Correct?

I don't know of any ... however, would this help?

class User < Lafcadio::DomainObject
fields do
text 'fname'
text 'lname'
end
end

You can have fields perform actions at the end of the block. I don't know if
this is good enough, or if you really need it at the end of the class def.

--
-- Jim Weirich jim@weirichhouse.org http://onest...
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Glenn Parker

5/31/2005 1:02:00 AM

0

Francis Hwang wrote:
>
> It feels like, from perusing the archives, there is currently no way to
> be notified when a class definition is finished. Correct?

Not that I could find, and I've mentioned this as an annoying limitation
of Ruby myself.

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoi...

Francis Hwang

6/2/2005 3:21:00 AM

0


On May 29, 2005, at 8:54 PM, Jim Weirich wrote:

> On Saturday 28 May 2005 11:05 pm, Francis Hwang wrote:
>> I wanted to trigger some methods to undefine instance methods of
>> 'fname' in User, but I can't do that with Class.inherited -- because
>> at
>> the time that the User class is being defined, I don't know that I'm
>> looking for global methods named 'fname' and 'lname'.
>>
>> It feels like, from perusing the archives, there is currently no way
>> to
>> be notified when a class definition is finished. Correct?
>
> I don't know of any ... however, would this help?
>
> class User < Lafcadio::DomainObject
> fields do
> text 'fname'
> text 'lname'
> end
> end
>
> You can have fields perform actions at the end of the block. I don't
> know if
> this is good enough, or if you really need it at the end of the class
> def.

Thanks for the suggestion, but that's probably too cumbersome. For the
time being I suppose I'll just have to warn users of the lib not to
have global methods named the same as the auto-methods. It's probably
not a common problem, anyway.

Francis Hwang
http://f...

Nicholas Seckar

6/2/2005 3:40:00 AM

0

Francis Hwang wrote:

>
> Thanks for the suggestion, but that's probably too cumbersome. For the
> time being I suppose I'll just have to warn users of the lib not to
> have global methods named the same as the auto-methods. It's probably
> not a common problem, anyway.
>
> Francis Hwang
> http://f...
>

Perhaps Jamis Buck's BlankSlate might be what you're looking for?

See here: http://onestepback.org/index.cgi/Tech/Ruby/Blank...

Feel free to echo this to the list if it's the correct answer.


IMPOSSIBLE, adj:

(1) I wouldn't like it and when it happens I won't approve;
(2) I can't be bothered;
(3) God can't be bothered.
- The Hipcrime Vocab by Chad C. Mulligan

Francis Hwang

6/2/2005 5:07:00 AM

0


On Jun 1, 2005, at 11:39 PM, Nicholas Seckar wrote:

> Francis Hwang wrote:
>
>>
>> Thanks for the suggestion, but that's probably too cumbersome. For
>> the time being I suppose I'll just have to warn users of the lib not
>> to have global methods named the same as the auto-methods. It's
>> probably not a common problem, anyway.
>>
>> Francis Hwang
>> http://f...
>>
>
> Perhaps Jamis Buck's BlankSlate might be what you're looking for?
>
> See here: http://onest.../index.cgi/Tech/Ruby/Blank...
>
> Feel free to echo this to the list if it's the correct answer.

Don't you mean Jim's BlankSlate? Seeing as http://onest... is
Jim's blog and all.

Anyway, as I said before, that doesn't work in my odd case because
Lafcadio uses class methods within the class definition, and my code
would need to know that stuff, but it's invoked after the class
definition begins, so it wouldn't work in this case.

Francis Hwang
http://f...