Bug #5067
closedBasicObject's constant lookup documentation
Description
Take a look at https://github.com/ruby/ruby/pull/31 .
It's OK for me to merge this request -- no technical difficulties -- but is it a right thing to be documented?
Updated by mame (Yusuke Endoh) over 13 years ago
Matz explicitly stated in #3768, that it is intended that BasicObject does not
resolve constants beyond itself. But he does not make mention to the workaround
by using const_missing.
--
Yusuke Endoh mame@tsg.ne.jp
Updated by matz (Yukihiro Matsumoto) over 13 years ago
I agree to merge this documentation clarification, but without the last five lines. The work around may or may not work, depending on the applications's requirement. I don't want to encourage the half-baked solution in the document.
matz.
Updated by trans (Thomas Sawyer) over 13 years ago
But that was the main point of adding the documentation! And how can it be "half-baked"? What other solution is there?
The documentation states that it is "if" you need to reference constant normally from within a basic object, then the solution is #cont_missing. Maybe it needs to be worded better, but that's the ONLY solution there is.
Maybe you do not write DSL often, I work with them very often. Having known this upfront could have saved me many hours and days of headache. And saved me from reporting it as a bug. It sure seems like bug at first. But you and others have explained to me why it is not a bug. It only seems right to explain that in the documentation and to give the ONLY work around if it is needed.
Updated by matz (Yukihiro Matsumoto) over 13 years ago
Well, BasicObject is a blank slate, and adding const_missing to it could affect all classes in the Ruby class hierarchy. Even though it might solve your problem, that could have huge side effect, e.g. entering infinite loop.
OKay, as a compromise, I can accept more clarified version of workaround.
class Foo < BasicObject
def self.const_missing(name)
::Object.const_get(name)
end
end
How do you think?
matz.
Updated by trans (Thomas Sawyer) over 13 years ago
Ah, I see. Yes, your example is what is meant.
Updated by drbrain (Eric Hodel) over 13 years ago
In light of the workaround required to access Ruby classes descending from Object I think "very useful as the base class for DSLs" is not quite accurate.
I think the first paragraph should say something more like "useful for creating object systems that won't be interfered with Ruby's object system" and the second paragraph should explain various workarounds required.
It might be useful to mention you can include Kernel in BasicObject descendants to provide access to methods like open, require, etc.
Updated by trans (Thomas Sawyer) over 13 years ago
@eric (Eric Anderson) Makes sense. I think "system" might be too overloaded a word, maybe "hierarchy"?
Should I work on wording and update example?
Updated by trans (Thomas Sawyer) over 13 years ago
Here is my improved documentation:
https://github.com/trans/ruby/commit/70a66e08780b5bc77fb47a91cbefc372147a716e
If overall satisfactory, please merge and tweak as needed.
Updated by drbrain (Eric Hodel) over 13 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r32700.
Shyouhei, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
- object.c: Add usage documentation for BasicObject. Based on patch
by Thomas Sawyer. [Ruby 1.9 - Bug #5067]