|Problems? Is your data what you think it is?|
Re^4: How Large Does Your Project Have To Be to Justify Using Moose? (modular)by stvn (Monsignor)
|on Oct 23, 2011 at 18:05 UTC||Need Help??|
Even if you don't have Moose generate accessors, then it generates a constructor that still exposes the attributes.
By default, yes it does. But it is easily remedied.
And if you don't generate accessors then you can't make use of many roles.
Not sure what that even means because roles and accessor generation have nothing to do with one another. Care to clarify this?
I'm starting to realize that there are people (I can't tell how many / how common yet) that can't even really conceive of designing a class without jumping straight to building a list of attributes, even after you explain to them that they should design the interface before designing the attributes (which are part of the implementation). Moose certainly encourages that mindset.
Again, I really fail to see how Moose encourages this. Just because Moose makes it easy to build attributes, that in no way forces not think about the interface first. Moose is just a tool to help you write your classes, it is still your responsibility to actually design the classes.
But I'd likely implement the square as a list of 4 x/y coordinates. And I'm not sure how I want to store the coordinates (as pairs or as parallel arrays or ?). I don't even think too much about how I'm going to implement the square's data when I'm defining the interface for the square.
So, again, Moose doesn't prevent you from doing this.
What this buys you over doing it by hand is basically automated (private) accessor construction and proper constructor initialization for any subclasses (via BUILD). It is also pretty concise and (with the exception of init_arg => undef which is a little odd) is pretty easy to understand (once you know Moose of course).