From: "David A. Black" <dblack@...>
Date: 2005-04-19T05:01:12+09:00
Subject: Re: [ANN] Article: Seeing Metaclasses Clearly

--927295978-337954697-1113854452=:31436
Content-Type: MULTIPART/MIXED; BOUNDARY="927295978-337954697-1113854452=:31436"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--927295978-337954697-1113854452=:31436
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

On Mon, 18 Apr 2005, Gavin Kistner wrote:

> On Apr 18, 2005, at 6:33 AM, Florian Gro=DF wrote:
>> Nice article, but I disagree in the point that @@vars are simpler than=
=20
>> class instance variables. Class instance variables have odd semantics in=
=20
>> the current Ruby which means that they will probably do some detail=20
>> different than you expect.
>
> But you have to do:
>
> class Foo
> =09@var1 =3D []
> =09@var2 =3D {}
> =09class << self
> =09=09attr_accessor :var1, :var2
> =09end
> end
>
> to get reasonable access to those class instance variables inside an inst=
ance=20
> method, and even then you have to do self.class.var1
>
>
> Once you 'get it' it's not TERRIBLY difficult, but I would say that the a=
bove=20
> is more than enough justification for calling @@foo simpler. Simpler, but=
=20
> also confusing in the inherited-class cases.

Also, they're different.  In 2.0, it sounds like they will be more
similar to each other, because class vars will be truly scoped per
class.  I'm not in favor of that.  Class variables, in my view, are
responsible already for a huge amount of misunderstanding of
*instance* variables (because the @/@@ thing always makes people think
there must be some connection or similarity between the two entities,
and then they get confused when there isn't).

I'm not sure what the best thing would be.  I tend to root for the
removal of class variables entirely.  I might even be able to tolerate
#class_attr_* methods, which actually make no sense (since there's
really no more reason to create special methods, in that area, for
Class objects than any other object) but might keep things smoother.


David

--=20
David A. Black
dblack@wobblini.net
--927295978-337954697-1113854452=:31436--
--927295978-337954697-1113854452=:31436--