From: Yukihiro Matsumoto Date: 2006-07-04T04:03:07+09:00 Subject: Re: About 1.9 #__method__ feature. Hi, In message "Re: About 1.9 #__method__ feature." on Tue, 4 Jul 2006 03:11:04 +0900, transfire@gmail.com writes: |> |Using BasicObject as parent removes (almost) all kernel methods which |> |ensures no name clashes when using the OpenObject. Problem is sometimes |> |those removed methods are needed. So the important ones are available |> |by shadow methods, like __send__ even though #send is removed. Problem |> |is A) how many and which kernel methods should be shadowed; all of |> |them? and worse B) it means users have to be aware when a subclass of |> |BasicObject might be used and call the LCD, ie. shadow methods instead |> |of regular methods. |> |> I don't know what you expect for BasicObject and OpenObject. |> BasicObject is a BasicObject what it is. Could you describe what you |> want and what you expect first please? BasicObject may not be the |> answer for your problem. If it's not the right answer, tweaking it to |> adopt your requirement might not be a good idea. | |OpenObject is just like OpenStruct, but it is faster and removes |methods that would get in thte way using BasicObject, for example |#class. Hmm, and you cannot use private methods in the subclass of OpenObject. What should we do? Maybe you can define your own version of BlankSlate that makes every required method into private, instead of undef'ing it. I just revisited separating two namespaces, but it would break 80-90% of Ruby programs. Even though I accept _some_ code breakage in 1.9, it's just too much. matz.