From: Josh Cheek <josh.cheek@...>
Date: 2011-12-21T23:08:03+09:00
Subject: Re: Accessing class instance variables from an instance?

--0016e6de0078f28aa704b49ab10e
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Dec 21, 2011 at 2:50 AM, Robert Klemme
<shortcutter@googlemail.com>wrote:

> On Wed, Dec 21, 2011 at 5:34 AM, Josh Cheek <josh.cheek@gmail.com> wrote:
> > On Tue, Dec 20, 2011 at 9:42 PM, Khat Harr <myphatproxy@hotmail.com>
> wrote:
> >
> >> Actually, now that I'm thinking about it the existing behavior sort of
> >> what makes more sense.  I'd think that subclasses would be better
> >> instantiating their own class vars rather than expecting a unique copy
> >> of the superclass var.  I can see why you'd want the class instance vars
> >> rather than modifying the existing mechanic.  On the other hand, maybe a
> >> new variable type to encapsulate the behavior of a class instance var in
> >> the way that it's being used here would be something worth discussing?
>
> I opt for completely removing class variables because they lead to
> confusion without end.  I don't see the need for a new type of
> variable either.  For one, it is an open question if state really
> should be managed on the class level.  It may be much more appropriate
> for Shareed to have a container object which holds a number of
> instances and manages common state.  If you need that state in
> instances you can always have a backward reference to the container.
> (You need that anyway if you want to avoid joining multiple containers
> for a 1:n relationship.)  If state is managed by the class then you
> cannot partition the set of instances.  And in case of this thread it
> seems state is better not held in the class instance, because that
> should manage class state while here we are talking about state which
> is common to all instances.  Just because it's easy to do or
> convenient does not mean that storing this in the class is necessary a
> good idea.
>
> > I don't see any point in that, class ivars seem sufficient to me. What
> > would be nice, though, is an attr_accessor equivalent that defines
> methods
> > for both the class and instance.
>
> I find that a bad idea: this easily leads to confusion and if you want
> the same attribute in the class and all instances then you better make
> that explicit.  This should be a very rare case anyway.  The only
> thing which comes to mind where this seems remotely useful would be
> default values for fields.  But in this case I'd rather name fields
> differently because they mean something different:
>
> class Foo
>  class <<self
>    attr_accessor :name_default
>  end
>
>  attr_writer :name
>
>  def name
>    @name || self.class.name_default
>  end
> end
>
>
> irb(main):025:0> Foo.name_default = "X"
> => "X"
> irb(main):026:0> f = Foo.new
> => #<Foo:0x1018c06c>
> irb(main):027:0> f.name
> => "X"
> irb(main):028:0> f.name = "bar"
> => "bar"
> irb(main):029:0> f.name
> => "bar"
> irb(main):030:0> Foo.name_default
> => "X"
>
> Kind regards
>
> robert
>
> --
> remember.guy do |as, often| as.you_can - without end
> http://blog.rubybestpractices.com/
>
>
Yeah, sorry, it was late. The need I actually come across isn't state
based, but functionality based. For example, HTTParty's get method. From
outside it's nice to be able to say `HTTParty.get(...)` but from inside
they don't want to have to say `self.class.get(...)` so that is an example
of a class level method that should be available to instances without
having to go find the class. I find that need occasionally. Or sometimes
I'm looking at some method and realizing it really could be a class method,
and that no one can use it without instantiating, but it's pretty obnoxious
to have to instantiate a class just to call some method that doesn't depend
on instances.

--0016e6de0078f28aa704b49ab10e--