From: Mark Volkmann <r.mark.volkmann@...>
Date: 2006-04-11T04:14:43+09:00
Subject: Re: Quick syntax question

On 4/10/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Tue, 11 Apr 2006, Mark Volkmann wrote:
>
> > On 4/10/06, Austin Ziegler <halostatue@gmail.com> wrote:
> >> On 4/10/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:
> >>> Consider the following three class definitions:
> >>>
> >>> class Foo
> >>>   def self.bar
> >>>     @@bar
> >>>   end
> >>>   def self.bar=(val)
> >>>     @@bar = val
> >>>   end
> >>> end
> >>>
> >>> class Foo
> >>>   class << self
> >>>     def bar
> >>>       @@bar
> >>>     end
> >>>     def bar=(val)
> >>>       @@bar = val
> >>>     end
> >>>   end
> >>> end
> >>>
> >>> class Foo
> >>>   class << self
> >>>     attr_accessor :bar
> >>>   end
> >>> end
> >>>
> >>> Am I correct in believing that they are equivalent? If not, how do they
> >>> differ?
> >>
> >> They are not equivalent. The first two are the same,
> >
> > That's good to know. I can't see any reason to prefer the second over
> > the first. It's a lot more noisy.
>
> class C
>    class << self  # 100% class stuff that is hard to do with 'Class.' below
>
>      def a_class_method() end
>
>      alias one_class_method to_another
>
>      define_method('another_class_method'){ 42 }
>
>      %w( a b c d e f g ).each{|of_seven_class_attributes| attr of_seven_class_attributes}
>
>      undef a_blown_away_class_method
>
>      remove_method 'blow_this_method_of_off_the_class'
>
>      undef_method 'stop_responding_to_this_class_method_at_all'
>
>      public 'a'  # the class method
>    end
> end
>
> 'class << self' is 100 time more consistent and, as soon as you break one
> method 100 times less noisy imho.

Thanks Ara!  I was only thinking about defining class methods.  You
gave me lots to consider that I wasn't before.

I do think it's a weird syntax though. It's a class definition inside
a class definition, but it isn't defining a nested class like many
Ruby beginners might guess at first glance.

--
R. Mark Volkmann
Object Computing, Inc.