That's funny, given that what else you said in this thread is only slightly truncated at:
If I never have to write an accessor generator by hand again, great!
I use Moose for anything with more than one object attribute.
Otherwise, your question is obviously just rhetorical since I don't know what you do or don't do when you design. Though, certainly, one should take a self review of design prowess with a grain of salt.
I also never claim that using Moose makes good OO design impossible. If you can fight the tendency that I pointed out, then good for you. Though, it doesn't really sound like it, even just in this thread. :)
| [reply] |
That's funny, given that what else you said in this thread is only slightly truncated at:
Sure, but when I write code that's completely stateless, I rarely need polymorphism and probably don't need objects at all.
Yet even if someone's going to write OO spaghetti, I'd rather debug Moosified OO spaghetti than hand-rolled OO spaghetti, because there's a non-zero chance that the Moose version at least pretends to care about things like encapsulation and declaration of attributes.
| [reply] |
Sure, but when I write code that's completely stateless,
Eh? Just because an object has state, doesn't mean it has to expose its internal state on an API.
My objects typically aren't stateless. Most of the time, the external world will not be able to peak at the internal implementation of state.
I rarely need polymorphism and probably don't need objects at all.
When I write code and I have the need to group a bunch of attributes in a container, I use a hash, and probably don't need objects at all.
But if I want to encapsulate something, I use objects, and actually encapsulate by not making most of the attributes visible.
| [reply] |
