{"comment":{"url":"https://api.github.com/repos/sporto/imm/comments/14108409","html_url":"https://github.com/sporto/imm/commit/07cf45aa6294962e7d5c6c814988c5b068e5ee28#commitcomment-14108409","id":14108409,"user":{"login":"sporto","id":1005498,"avatar_url":"https://avatars.githubusercontent.com/u/1005498?v=3","gravatar_id":"","url":"https://api.github.com/users/sporto","html_url":"https://github.com/sporto","followers_url":"https://api.github.com/users/sporto/followers","following_url":"https://api.github.com/users/sporto/following{/other_user}","gists_url":"https://api.github.com/users/sporto/gists{/gist_id}","starred_url":"https://api.github.com/users/sporto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sporto/subscriptions","organizations_url":"https://api.github.com/users/sporto/orgs","repos_url":"https://api.github.com/users/sporto/repos","events_url":"https://api.github.com/users/sporto/events{/privacy}","received_events_url":"https://api.github.com/users/sporto/received_events","type":"User","site_admin":false},"position":null,"line":null,"path":"","commit_id":"07cf45aa6294962e7d5c6c814988c5b068e5ee28","created_at":"2015-10-31T09:09:53Z","updated_at":"2015-10-31T09:09:53Z","body":"Oop vs functional approach\n\nHey, what I found out when using this lib in a large project boils down to the difference between writing code in OOP vs a functional way. This library embraces a OOP which is less flexible, let me explain why.\n\nSay you have a collection object which has a total method:\n\ncollection.total\n\nThis is very common in OO languages. Then you want to filter the collection:\n\ncol2 = collection.filter(...)\n\nThen you end up with a new collection wth just the records you want. But then you found out that .total is not available anymore, the filter returned a plain array instead of a wrapped collection object. This is a common issue. This is one place where OO rather fails.\n\nTo avoid this the implementer of the collection wrapper must provide methods for all possible things that always return another wrapped collection. So you could call .total in the filtered collection. This is a lot of work and this is where Imm let us down.\n\nInstead the functional approach is much simpler. You collection is just a plain structure eg an array. It doesn't have any fancy methods.\n\nYou simply call a function with it:\n\ntotal(collection)\n\nThen if you filter the collection of any other thing you can still call .total on the result. This is a lot more flexible and doesn't require you to keep wrapping the collections.\n\nThis is what we have done instead. I will recommend you to do the same, just create a set of functions that take either seamless-immutable or immutablejs collections and do what you need. \n\nWe also created https://github.com/Versent/siu/blob/master/readme.md for this but is not well documented. Sorry.\n\nI hope this helps\n\nSebastian\n\n> On 31 Oct 2015, at 9:40 AM, Derek Yau <notifications@github.com> wrote:\n> \n> @sporto hey, just curious - I've been looking for a library like this which wraps immutable objects with a nice CRUD interface (.get, etc.) like you have here with Imm. Is there a reason why its discontinued? Is there a better option to use? Or should I go back to just using a normal Immutable.js/Seamless-immutable making use of something like lodash to do matching grabbing out ids?\n> \n> any guidance/thoughts you have here would be awesome thanks!\n> \n> —\n> Reply to this email directly or view it on GitHub.\n> \n"}}