Oh, class instance variables when self = Mod. Yes, you can do that, and without the "class [[ self" (have to use square brackets rather than angle) notation. I think this is the same idea:
module Mod
end
def Mod.c=(v)
@c = v
end
def Mod.c
@c
end
Mod.c = 10
puts Mod.c
What I like about giving the Module name explicitly when defining "class methods" (def Mod.c and the like) is that since these are supposed to be "singleton" methods, I think it helps visually to see what class/module the methods are being defined on. People like the "class [[ self" syntax (again, left bracket for left arrow; which I haven't discussed in lecture) because they imagine they are going to move the methods around in source code, from one class to another, and they don't want to change the explicit name of the class/module).
Yes, I do, but this is truly a "personal taste" area. I don't think I overplayed my preference in lecture.
A lot of people like "self" so that it's easier to move stuff around. But I figure: If it's a class method, and if the hierarchy is shallow, are you really going to move a class method around? I doubt it. Were the inheritance hierarchy deep, then self. would make more sense.
More of a theoretical question:
Should modules be allowed to have state? I could do such a think like follows:
module Mod
class << self
attr_accessor :state_var
end
end
class A
include Mod
def modify_state_var
Mod.state_var = 4
end
end
But is this anything like what one should be doing?
@Gabriel Hase
Modules don't have state (one exception: They can have @@ class variables).
They can manipulate instance variables, but those instance variables are for whatever "self" is in play.
Observe:
module Foo def bar=(v) @bar = v end def bar @bar end end class Sub include Foo end s = Sub.new s.bar = 5 puts s.barBut that's different from what Gabriel asked, which was about 'class instance' variables for modules.
@Ron Newman
Oh, class instance variables when self = Mod. Yes, you can do that, and without the "class [[ self" (have to use square brackets rather than angle) notation. I think this is the same idea:
What I like about giving the Module name explicitly when defining "class methods" (def Mod.c and the like) is that since these are supposed to be "singleton" methods, I think it helps visually to see what class/module the methods are being defined on. People like the "class [[ self" syntax (again, left bracket for left arrow; which I haven't discussed in lecture) because they imagine they are going to move the methods around in source code, from one class to another, and they don't want to change the explicit name of the class/module).
This surprised me, however, after executing the above code:
@Ron Newman
c is not a class method on Foo. It's a class method on Mod. :-)
Thanks. And it also sounds like you prefer that people write
def Foo.method
...
end
rather than
def self.method
...
end
when defining class methods.
@Ron Newman
Yes, I do, but this is truly a "personal taste" area. I don't think I overplayed my preference in lecture.
A lot of people like "self" so that it's easier to move stuff around. But I figure: If it's a class method, and if the hierarchy is shallow, are you really going to move a class method around? I doubt it. Were the inheritance hierarchy deep, then self. would make more sense.