On Mon, Dec 8, 2014 at 10:23 PM, Arron Norwell <[email protected]> wrote:

On Monday, December 8, 2014 2:35:12 PM UTC-5, Xavier Noria wrote:
>>
>> There's no solution, in general you cannot design AS::Dependencies with
>> emulation in mind. It does not even lookup in "ancestor" paths!
>>
>> It doesn't emulate, it cannot emulate, it has its own rules.
>>
>
> I'm convinced that emulation of the ruby behaviour is not possible.
> However, I'm still not fully understanding this. My example is really
> about how the behaviour differs based on whether or not certain constants
> are already loaded -- all I want to do is handle the "constant already
> loaded" case in the same way as the "constant not yet loaded" case. As far
> as I can tell, I'm not really proposing a new behaviour, because it is
> already the behaviour one gets if the constant has not yet been loaded. I'm
> still trying to understand if there's a reason why it cannot work like
> this, or if it is just for backwards compatibility.
>

The proposal is, couldn't we try A::B::M in

    module A::B
      class C
        M
      end
    end

even if A::M existed?

Question, why?

Case 1) Because Ruby would.

Answer 1) Ruby wouldn't in

    class A::B::C
      M
    end

and const_missing has no way to know in which one of the cases the call
happened. So that would fulfill the expectation in one case to break it in
another case. Emulating Ruby is not a design driver for AS::Dependencies
because it cannot be done.

Case 2) To have it behave the same regardless of the existence of A::M.

Answer 2) We agree this rule is dubious, but it is the rule that prevents
AS::Dependencies from walking parent namespaces in

    A::B::C::M

and we cannot change that rule at this point in the game due to backwards
compatibility.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Reply via email to