On Oct 19, 12:22 pm, "Rick DeNatale" <rick.denat... / gmail.com> wrote:
> On 10/19/07, ara.t.howard <ara.t.how... / gmail.com> wrote:
> > On Oct 18, 2007, at 11:22 AM, David A. Black wrote:
>
> So what was my point here?  Oh yes. I was talking about what happens
> when you make certain changes to the inheritance structure.  If we
> had:
>
> class A
> end
>
> class B < A
>      @@cv = 42
> end
>
> And then later
> class A
>     @@cv = 57
> end
>
> Ruby currently at most warns about a conflict then goes ahead and adds
> a new class variable to A, leaving the existing one in C.

Ok, you've used a similar example multiple times now, so my curiosity
is getting the best of me - do you actually code this way, or are you
trying to come up with a contrived example to show the alleged
problems with class variables? Wouldn't you typically initialize the
class variable in the "superest" class only?

> ...
> On the other hand, there might be subtleties I can't yet fathom, much
> like I still don't understand why 1.9 changed the semantics of:
>
> module M
>     def meth
>         "M"
>     end
> end
>
> class A
>    include M
> end
>
> class B < A
>    def meth
>          "B"
>    end
> end
>
> class C
>     include M
> end
>
> C.new.meth
>
> So that in 1.9 this used to result in "M" but then they changed it
> back to the 1.8 semantics which ignore the re-inclusion and results in
> "B".

Should 'class C' be 'class C < B' ?