Forum: IronRuby Code Review: MethodLookup

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tomas M. (Guest)
on 2008-10-08 08:26
(Received via mailing list)
Attachment: MethodLookup.diff (0 Bytes)
tfpt review "/shelveset:MethodLookup;REDMOND\tomat"

'alias' keyword, alias_method and public/private/protected methods look
the method up in Object if called on a module, which we didn't do
Also, 'super' keyword doesn't use current 'self' if called in
class_eval/instance_eval.

Tomas
Curt H. (Guest)
on 2008-10-08 08:53
(Received via mailing list)
Changes are largely good.  The change involving
MetaObjectBuilder.TreatRestrictionsAsConditions is pretty awkward, but
I'm sure you think so too and there don't seem to be any terribly clean
alternatives.

In the case we were looking at earlier today, will
ResolveMethodFallbackToObject find Module.freeze or only Object.freeze?
Tomas M. (Guest)
on 2008-10-08 10:11
(Received via mailing list)
Yes, TreatRestrictionsAsConditions is a little ugly, but I don't see any
much cleaner way how to achieve the same.

I don't remember the exact details, let's revisit it tomorrow.

Tomas
Curt H. (Guest)
on 2008-10-09 12:56
(Received via mailing list)
I ran my test case against MRI and determined that MRI itself would only
find Object.freeze under these circumstances.  I suspect that the
original code in edge Rails is therefore incorrect, in that it will
create a method alias for Object.freeze instead of Module.freeze.

Bottom line: you're doing the same thing as MRI so the code is okay. :)
This topic is locked and can not be replied to.