5 ms·
Nice. Are you trying to tell me that that example doesn't appear to try and avoid state?
by xd 14y ago
Nice. Are you trying to tell me that that example doesn't appear to try and avoid state?
- rads 14y agoThat example is full of state. There's nothing to prevent you from calling any of those setX methods at a later point in time and changing the object's state. That interface very well could avoid state, but Swiftmailer doesn't seem to be implemented in that way. [1] The stateless way would be to return an entirely new Swift_Message instance with each setX method. In languages that aren't built with immutability in mind, like PHP and Java, you end up instantiating and throwing away a lot of objects. Sometimes it doesn't matter, but when it does you use a mutable Builder to create the immutable instances. [1] http://swiftmailer.org/docs/messages.html http://swiftmailer.org/docs/messages.html
- xd 14y agoThat example is full of state. That's why I said it appears to try and avoid state. Either way, as far as I'm concerned it's an horrific way to write code in an imperative language such as PHP.
- mhitza 14y agoI beg to disagree. It's a variation of the builder pattern and I find it quite useful, thank you.
- true_religion 14y agoNot to me. setX is reminicent of Java to me, and of small talk attribute setters/getters before it. Both of those languages elevate state to the point of godhood.
- xd 14y agoIt's not about the setters/getters directly, it's the way they are being called by returning references to the parent object in each method call.