3 ms·

"The signature of 'this shouldn't be a class' is that it has two methods, one of which is init." [0] Why not write a function? This addresses all of the ob

"The signature of 'this shouldn't be a class' is that it has two methods, one of which is __init__." [0] Why not write a function? This addresses all of the objections. Then refactor by pulling out concerns into other functions. Need to share logic around the functions? Use a decorator. Passing too many attributes? Create a class to contain them. I think classes are best avoided until it's obvious that encapsulating state provides a benefit, which I don't see in this case. [0] https://www.youtube.com/watch?v=o9pEzgHorH0&t=3m https://www.youtube.com/watch?v=o9pEzgHorH0&t=3m

programminggeek 13y ago
I actually like class methods for one particular benefit - namespacing. Actually, in Ruby, I use modules for that, but same difference in Ruby right...? Functionally though, there isn't much difference between Module.do_stuff() and module_do_stuff() and if you are writing functional code, there isn't much reason to care either way too much. Most Ruby I see though isn't terribly functional.
stormbrew 13y ago
Comparisons to python are difficult here because in Ruby there's no such thing as an object that doesn't have a class. Even the classes have classes (which is, as I touched on elsewhere, what class methods actually are -- instance methods on the class). You can store a proc in a variable or a constant, but you're getting into some very ugly patterns at that point and you still haven't really left classes behind. In Ruby everything is encapsulated and there's really no point in fighting that.
- lmm 13y ago
  > Comparisons to python are difficult here because in Ruby there's no such thing as an object that doesn't have a class. Even the classes have classes (which is, as I touched on elsewhere, what class methods actually are -- instance methods on the class So exactly the same as Python then? > You can store a proc in a variable or a constant, but you're getting into some very ugly patterns at that point and you still haven't really left classes behind. How so? If you need to pass around something that quacks like a proc, do it as a proc.
  - stormbrew 13y ago
    > So exactly the same as Python then? Recently? Sort of, yes. Though in python it's more like everything has a blessed hash, and the assumption that everything is an object is much more thoroughly baked in in Ruby. Also the way that classes interact with their instances is quite different. For example, in python a member of the class that is not overridden in an instance also happens to be a member of an instance. This is how default attributes work: >>> class x(object): ... pass ... >>> x.blah = 1 >>> x().blah 1 This actually gives you something qualitatively like a static method (through the staticmethod decorator), it is callable from an instance as well as the class and behaves always as if it has no access to the instance's state. This kind of blending of instance and class doesn't happen in Ruby. The class is a completely distinct object with its own independent state, and is instantiated just like any other object, some syntactic sugar aside. It is an instance of class Class and its methods are the methods of class Class, while instances created by calling its #alloc method have the methods that are defined on it. Python now shares some concept of everything being an object, I'll grant, but their models remain quite different and you really do have to work significantly against the grain to effectively use ruby in a non-OO fashion. In ways you simply don't in Python.

"The signature of 'this shouldn't be a class' is that it has two methods, one of which is __init__." [0] Why not write a function? This addresses all of the ob

programminggeek 13y ago

I actually like class methods for one particular benefit - namespacing. Actually, in Ruby, I use modules for that, but same difference in Ruby right...? Functionally though, there isn't much difference between Module.do_stuff() and module_do_stuff() and if you are writing functional code, there isn't much reason to care either way too much. Most Ruby I see though isn't terribly functional.

stormbrew 13y ago

Comparisons to python are difficult here because in Ruby there's no such thing as an object that doesn't have a class. Even the classes have classes (which is, as I touched on elsewhere, what class methods actually are -- instance methods on the class). You can store a proc in a variable or a constant, but you're getting into some very ugly patterns at that point and you still haven't really left classes behind. In Ruby everything is encapsulated and there's really no point in fighting that.

lmm 13y ago
> Comparisons to python are difficult here because in Ruby there's no such thing as an object that doesn't have a class. Even the classes have classes (which is, as I touched on elsewhere, what class methods actually are -- instance methods on the class So exactly the same as Python then? > You can store a proc in a variable or a constant, but you're getting into some very ugly patterns at that point and you still haven't really left classes behind. How so? If you need to pass around something that quacks like a proc, do it as a proc.
- stormbrew 13y ago
  > So exactly the same as Python then? Recently? Sort of, yes. Though in python it's more like everything has a blessed hash, and the assumption that everything is an object is much more thoroughly baked in in Ruby. Also the way that classes interact with their instances is quite different. For example, in python a member of the class that is not overridden in an instance also happens to be a member of an instance. This is how default attributes work: >>> class x(object): ... pass ... >>> x.blah = 1 >>> x().blah 1 This actually gives you something qualitatively like a static method (through the staticmethod decorator), it is callable from an instance as well as the class and behaves always as if it has no access to the instance's state. This kind of blending of instance and class doesn't happen in Ruby. The class is a completely distinct object with its own independent state, and is instantiated just like any other object, some syntactic sugar aside. It is an instance of class Class and its methods are the methods of class Class, while instances created by calling its #alloc method have the methods that are defined on it. Python now shares some concept of everything being an object, I'll grant, but their models remain quite different and you really do have to work significantly against the grain to effectively use ruby in a non-OO fashion. In ways you simply don't in Python.