From: Brian Adkins Date: 2007-10-20T03:50:09+09:00 Subject: Re: Class instance variable idiom On Oct 19, 1:51 pm, "Rick DeNatale" wrote: > On 10/19/07, Brian Adkins wrote: > > > On Oct 19, 12:22 pm, "Rick DeNatale" 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. I'm still not buying it. I can't believe there's a scenario in Rails, to use your example, where a class variable is initialized in a base class after it was first claimed by a derived class, thereby creating two copies - or maybe I just don't want to believe it! :) I'm not saying class variables are perfect, but this notion of a subclass claiming a class variable before the superclass initializes it still seems contrived to me.