|> * is there any use-case for this method?
|
|We use it often in Rails.

Could you show us the concrete example? It is difficult for me to
imagine.

One case is to convert path names (file system paths) into constants.

In general, Rails uses inflections to convert names from different
contexts. In the router, for instance, "foo/bar" is used to represent
namespaces, which are then converted into "Foo::Bar" and then Foo::Bar.

|> * if Bar is not a class nor module, what kind error should be raised?
|>
|
|TypeError: "(…) is not a class/module"

Understood.

|> * is qualified_const_get an appropriate name for the function?
|>
|
|Unknown. It's what we call it in Rails ;)

How about

Foo.const_get("Bar::Baz")

Sounds good to me. Currently, trying to const_set or const_get a name with
:: in it produces a NameError, so it should not introduces new issues.

Hi,
In message "Re: Re: [ruby-trunk - Bug #5690][Open] Module#qualified_const_get"
on Wed, 30 Nov 2011 16:52:36 +0900, Yehuda Katz <wycats@gmail.com <mailto:wycats@gmail.com>> writes:
|> * is there any use-case for this method?
|
|We use it often in Rails.
Could you show us the concrete example? It is difficult for me to
imagine.

One case is to convert path names (file system paths) into constants.

In general, Rails uses inflections to convert names from different contexts. In the router, for instance, "foo/bar" is used to represent namespaces, which are then converted into "Foo::Bar" and then Foo::Bar.

"concrete exapmle" needs "what is the router?" and "when the router is used?".

I wrote qualified_const_get in Active Support. The rationale for that name was: 1) I didn't want to touch const_get. const_get is supposed to raise an exception if the argument is not a valid constant name and "Foo::Bar" is not a valid constant name. I didn't want to change that expectation in such a fundamental method. And 2) I wanted a name that was obvious. Given that a Ruby programmer knows const_get, he will instantly know what qualified_const_get is going to do. In that sense I don't think this method is more abstract than const_get, it is in my view rather the natural companion of const_get.

That's for the current name. If this was going to be considered for Ruby 2.0 I think I'd prefer this behavior to be available in const_get itself.

@Xavier Let me "qualify" that ;-) I think your reasoning made very good sense for adding to ActiveSupport. But becoming part of Ruby, there is the opportunity to do it "right", as your last statement concurs.

+1 from me, but modifying existing const_get. No incompatibility as "Foo::Bar" are currently invalid constant names. And const_set should be modified as well (raises a Name if the path up to the last constant name does not exist or is not a Module/Class).