On 10/19/07, Brian Adkins <lojicdotcom / gmail.com> wrote:
> 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?

Imagine that this code is not all in one file, but is spread out
between the implementation and usage of a  framework like, say, rails.
> > ...
> > 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' ?

Yes, thanks!

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/