Bug #5067: BasicObject's constant lookup documentation

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: doesn't matter

[shyouhei (Shyouhei Urabe)]

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?

[mame (Yusuke Endoh)]

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 [e-mail]

[matz (Yukihiro Matsumoto)]

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.

[trans (Thomas Sawyer)]

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.

[matz (Yukihiro Matsumoto)]

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.

[trans (Thomas Sawyer)]

Ah, I see. Yes, your example is what is meant.

[drbrain (Eric Hodel)]

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.

[trans (Thomas Sawyer)]

@eric Makes sense. I think "system" might be too overloaded a word, maybe "hierarchy"?

Should I work on wording and update example?

[trans (Thomas Sawyer)]

Here is my improved documentation:

https://github.com/trans/ruby/commit/70a66e08780b5bc77fb47a91cbefc372147a716e

If overall satisfactory, please merge and tweak as needed.

[drbrain (Eric Hodel)]

• 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]