Personally I agree with Aaron's use case or the general potential usefulness
of being able to query const_source_location where Aaron's suggestion is a
simplification over A::B (because the ruby user no longer HAS to know that
specific name, since the ruby user can just call a method instead, in this
case simply .const_source_location() ); and I love introspection anyway, so +1.
To the comment about the name (s): .source_location is in general better
than .const_source_location, in my opinion, for two reasons :
(1) it's shorter. :) We all like being concise ... two words are better than
three words most of the time. (One word may be even better but we often have
clashes with other names/methods, so two words are a bit better in these
cases.)
(2) even aside from (1), I believe .source_location is better as a name from
a design point of view. While Dylan reasoned that .const_source_location() makes
more sense, IMO we could actually go the other approach and say "ruby, I don't
quite care if it is a constant, or a method, or a class, or anything,
I just want to query the source_location to it". So I think it depends on
the point of view you have for the name. In my opinion, omitting "const_"
would be perfectly fine; also I struggle with things such as "when to use
class_eval or instance_eval" so I am all for simpler names in general. ;)
Now we do have Method#source_location but I think and also const_source_location
as well - but I think it would be simpler to "unify" towards one general name,
no matter what that name may be, if we look at it from the point of view of
"how ruby users may want to use the feature". So from that point of view,
from a ruby user perspective, I think it would be better to omit "const_"
completely. But this is quite secondary; IMO the use case described makes
sense.