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.  ¨Β§δ τθιξτθατ συβγμασσεσ χουμβε βεττες
>> instantiating their own class vars rather than expecting a unique copy
>> of the superclass var.  ¨Β γασεχθωου§χαξτ τθγμασιξσταξγε φαςσ
>> rather than modifying the existing mechanic.  ¨ΒτθοτθεθαξδναωβεΎ ξεφαςιαβμε τωπε το εξγαπσυματτθβεθαφιος οζ γμασιξσταξγε φαιξ
>> 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/