From: "David A. Black" Date: 2009-10-12T06:56:11+09:00 Subject: Re: Class Level inheritable attributes - are we there yet? --1926193751-337301410-1255298155=:16945 Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-337301410-1255298155=:16945" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1926193751-337301410-1255298155=:16945 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi -- On Mon, 12 Oct 2009, dreamcat four wrote: > On Sun, Oct 11, 2009 at 6:55 PM, Robert Klemme > wrote: >> Having said that I am not sure that you actually need a language construct >> when you can do this: >> >> >> class A >>  class <>    def foo >>      @foo || superclass.foo >>    end >>  end >> > > It shouldn't be mandated to re-invent the wheel in any programming > language, even if its fun style / fun to write. Here is why Robert: > because you would have just put 2 bugs into your code. But using the available techniques in a language to put together something higher level is not "re-inventing the wheel" (unless you do it repeatedly). The language cannot be expected to incorporate an abstract construct for every use case. > 1) It breaks when you want to set foo = nil in a subclass. You can fix this with a defined? test. > 2) Not having an accessor definition will break other code. > > puts A.instance_variables.inspect > => ["@foo"] > puts B.instance_variables.inspect > => [] > puts C.instance_variables.inspect > => ["@foo"] That's not broken; it just means that what Robert is doing isn't identical to what, say, attr_accessor does. You could modify Robert's code to assign to the instance variable the first time around rather than just examining it, or something like that. > Most people would try / expect to fix by putting attr_accessor :foo at > top class A. It simply doesn't work and the regular accessor is not > inherited. It is inherited; that is, given this: class A attr_accessor :x end class B < A end instances of B will have an x attribute. But, as you say, this isn't relevant to the class instance, and if people try to do it in order to address class-level state, they just haven't yet learned enough about the Ruby object model to know that things don't work that way. So they'll learn :-) > Because in Ruby the Class is instantiated as an instance of > object. You could probably imagine a little imaginary OO professor (A class is actually an instance of Class.) > tugging at your clothes and saying 'tut tut, such a shame' or > something. And you might argue back that the point was that these > aren't bugs if you understand the limitations etc, etc. Just like > being back at school eh? But i can assure you when any real programmer > in the real world comes along to use your classes and / or modify your > code, these holes are eventually surface as real breakages / bugs. I don't know whether Robert regards them as bugs or not, but I think the main point is that there a whole world of this stuff you can do trivially in Ruby. Besides, the examples we send back and forth on ruby-talk aren't necessarily fully field-tested; that's not really the point of the forum :-) > Heres my own top 3 recommendations: > > * Give up / don't use any. Avoid if possible. > > * Use the activeresource class inheritable accessor. I guess that's > not so much of a stretch if you are already depending upon > activeresource for other things. > > * Request a real language implementation in ruby core because class is > an object. It would be entirely a matter for the ruby development team > to decide whether they would want to implement it, and/or how. I'm > very surprised no-one has asked for this on 1.9 line, or to change the > existing @@ behaviour since are changed the block level variable > scoping and many other things. I'm still not seeing why it's so important that it be addressed in the core. Of course I'd be glad to see @@ changed to something more useful (Robert and I have been among the most vocal critics of class variables over the years :-) but I don't want to see classes special-cased when it comes to how they maintain their own state. They're objects, and objects maintain state with instance variables, which classes can easily do. I've often said that "because classes are also objects" is the answer to 75% of all questions about Ruby :-) That's actually why I don't like extra special cases for classes. Once people understand that they're objects, and let go of trying to view them as entirely special, many things fall into place and the language makes more sense. David -- The Ruby training with D. Black, G. Brown, J.McAnally Compleat Jan 22-23, 2010, Tampa, FL Rubyist http://www.thecompleatrubyist.com David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com) --1926193751-337301410-1255298155=:16945-- --1926193751-337301410-1255298155=:16945--