<div dir="ltr">Yeah, I think there is a distinction between code where you have control of everything and when you're using a framework such as rails. It is about whether you're the framework/language supports/is neutral/actively works against you taking a certain approach.<div><br></div><div>If you have control of everything then you are free to use immutable objects everywhere if you so choose, and get the advantages mentioned. If you take the common types of toy problems that are used as 'challenges' as part of the recruitment process, 9 out of 10 times your response will be "better" if you follow the immutable objects approach. But then when you're in a real world rails project there are a lot of assumptions made by the framework authors and code already in your project which may not make it the best/simplest approach, or invalidate the advantages.</div><div><br></div><div>Personally think this is why following 'extreme' approaches in toy or practice problems is useful, because it gives you a pure environment to experiment and practice; then you can spot small parts of your real applications where the techniques may apply.</div><div><br></div><div>2 other unconnected thoughts:</div><div><br></div><div>* In the DDD world, they split things into Entities (things with identity that change state over time, such as a Customer) and values which are immutable (such as Address)</div><div>* In the Event Sourcing / CQRS model updates to state and viewing current state are completely separated - all state changes are a log of updates from which a 'current state' is constructed. Because of the way this work, you can reconstruct your application state at any point in time since you started it - an analagous model would be how git works.</div><div><br></div><div>Thanks,</div><div>Roland</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 10:13 AM, Tom Armitage <span dir="ltr"><<a href="mailto:tom@infovore.org" target="_blank">tom@infovore.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Thu, Sep 10, 2015 at 8:49 AM, Jonathon Horsman <span dir="ltr"><<a href="mailto:jonathon@arctickiwi.com" target="_blank">jonathon@arctickiwi.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><div class="gmail_extra">given that having a data store as a shared global state the situation in the vast majority of apps? Surely shoe-horning immutable objects onto a mutable data store would always be the wrong solution?</div><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div></span><div>I'm sure someone will correct me if I'm wrong but - that's really a fallacy of the ActiveRecord pattern, right, where one domain object corresponds directly to its representation data store?</div><div><br></div><div>This is the sort of thing something like a Repository pattern solves, ie: you have a mutable data store, and a way of communicating to/from it (to save/update/delete records) - but your domain objects are actually separate. You retrieve data from the database, and use it to build immutable objects to pass around the application. Instead of mutating them, you replace them with new objects as/when - and then, when you come to saving it, your repository interface goes "oh-ho, this is really an edit to some rows", and it makes an UPDATE rather than just new rows everywhere - even though you've been making new objects in the application.</div><div><br></div><div>What that also means is you can represent something that might be stored in a single table as a collection of objects, or vice versa, something that's correctly distributed across tables with relationships as <i>fewer</i> objects. It breaks the direct link between A Thing and A Table. This is entirely counter to ActiveRecord, but AR is not the only way.</div><div><br></div><div>Disclaimer: I've never used this approach personally.</div><div><br></div><div>But: I can see the appeal (especially now I've explained it to myself).</div><div><br></div><div>As for "doesn't it make it more complex"; as usual, the answer's often <i>yes</i>; except the number of times I've continued to build on that foundation to a point where I either need to a) do a big refactoring or b) carry on in a string-and-glue manner means that, as usual, choosing to make something more complex is not always the worst idea if it more accurately represents the shape of the world. As ever, that's the hard part of making software: choosing when to make the decision to change direction.</div><div><br></div><div>I hope I've not totally misunderstood Repositories.</div></div>
</div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>