--1926193751-337301410-1255298155
6945
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
6945
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
> <shortcutter / googlemail.com> wrote:
>> Having said that I am not sure that you actually need a language construct
>> when you can do this:
>>
>>
>> class A
>> class <<self
>>  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  il 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
6945--
--1926193751-337301410-1255298155
6945--