15 Mar, 2010, flumpy wrote in the 41st comment:
Votes: 0
Careful with the buzzy language thing there…
15 Mar, 2010, David Haley wrote in the 42nd comment:
Votes: 0
…? Is it offensive to say that a language generates a lot of buzz?
15 Mar, 2010, flumpy wrote in the 43rd comment:
Votes: 0
I was kidding somewhat but I think "buzz" can be used to describe something as short lived and only popular because fashionable. I think describing something as buzzy brings the phrase "Buzz word" to mind, but that could just be me.

Whilst I would argue that indeed, ruby is fashionable, I am not so sure it will be short-lived ;)

edit: When I re-read your post I noticed you'd either ninja'd it or I hadn't read the part about "buzzy as in creates a lot of buzz" part..
15 Mar, 2010, flumpy wrote in the 44th comment:
Votes: 0
Runter said:
flumpy said:
Ah, but if I'd overridden new in any object, you wouldn't expect different behaviour either, no? The difference would be if I mentioned the behaviour in the docs, which then becomes reasonable and fair.

No other point really, either :D


Well, yeah, but I wouldn't expect you to be able to override the way class variables behave on principle unless you changed the C core.


Why not? What about for unit testing purposes? Am I missing something, or is't new a method call on the Class object? If so, it seems reasonable that you should be able to override/change it's functionality just like any other object…

Perhaps I am getting it wrong if you think that is one behaviour that should not change.. I don't know Ruby too well after all.
15 Mar, 2010, David Haley wrote in the 45th comment:
Votes: 0
flumpy said:
I was kidding somewhat but I think "buzz" can be used to describe something as short lived and only popular because fashionable. I think describing something as buzzy brings the phrase "Buzz word" to mind, but that could just be me.

Whilst I would argue that indeed, ruby is fashionable, I am not so sure it will be short-lived ;)

edit: When I re-read your post I noticed you'd either ninja'd it or I hadn't read the part about "buzzy as in creates a lot of buzz" part..

Oh. Well, I just meant that people talk about it a lot. Buzz != fad. And no, I didn't ninja-edit it, in fact the post hasn't been edited. :tongue:
15 Mar, 2010, Runter wrote in the 46th comment:
Votes: 0
flumpy said:
Runter said:
flumpy said:
Ah, but if I'd overridden new in any object, you wouldn't expect different behaviour either, no? The difference would be if I mentioned the behaviour in the docs, which then becomes reasonable and fair.

No other point really, either :D


Well, yeah, but I wouldn't expect you to be able to override the way class variables behave on principle unless you changed the C core.


Why not? What about for unit testing purposes? Am I missing something, or is't new a method call on the Class object? If so, it seems reasonable that you should be able to override/change it's functionality just like any other object…

Perhaps I am getting it wrong if you think that is one behaviour that should not change.. I don't know Ruby too well after all.


The discussion has been about how internally class variables are stored and language/syntax macros on how it is exposed to the user. I wouldn't expect you to be able to override inside of Ruby the way class variables are stored [at the lowest level], no. And also, it's probably intentional and shouldn't be changed. It should, however, be more well documented.
15 Mar, 2010, Tyche wrote in the 47th comment:
Votes: 0
Changing the example around…
class A
def A.set a
@@a = a
end
def A.get
@@a
end
end
class B
def B.set a
@@a = a
end
def B.get
@@a
end
end

B.set 1
p B.get
A.set 2
p A.get
p B.get


$ ruby classvar.rb
1
2
1

The only way to get unique class variables into your classes is to make certain you execute a reference to them at the lowest class in the inheritance chain first. It's like @@somevar automatically generates read/write accessor methods, or more accurately is very much like a global $globalvar with scope in the class heirarchy. Or as DavidHaley suggested they are automatically search for like method definitions.

That's why when a reference to @@a is executed a search for some @@a is conducted in the inheritance heirarchy and if not found is created in the context of the class that first referenced @@a.

class A
@@a = 1 # executed when class is read
def self.set x
@@a = 2 # executed when A.set is executed
end
end


So my first example
A.set 1
B.set 2

produces a class object scheme where the @@a ends up on the instances of only A
B——-A
@@a

The second example
B.set 1
A.set 2

produces a class object scheme where the @@a ends up on both instances
B——-A
@@a @@a
15 Mar, 2010, David Haley wrote in the 48th comment:
Votes: 0
That's very interesting. It confirms that it's basically searching up the instance/method tree (or whatever it is: you've got to account for mix-ins and other fun things too).

It reminds me of pure prototype inheritance, like what you might see in Self, Javascript, or Lua tables/metatables. There's a strict ordering for where one finds things: first check the thing, then check its parent things (superclasses, prototypes, whatever you want to call them) in whatever order is defined by the language (depending on things like multiple inheritance, mix-ins, etc.).

Thanks for confirming it, it makes me feel better about what's going on here.
40.0/48