tag:blogger.com,1999:blog-22587889.post2362782206886066939..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Pushing the envelope on OO and functional with ScalaAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-22587889.post-75578849114040576382011-05-13T23:13:46.847+05:302011-05-13T23:13:46.847+05:30(Since you are also a CouchDB user).
What do you t...(Since you are also a CouchDB user).<br />What do you think - would be profitable for Scala if CouchDB would be implemented in Scala ? Erlang is pure functional and Scala has very powerful support for functional programming.Andreyhttps://www.blogger.com/profile/02255884226845833932noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-41677215705294412102011-04-18T23:41:58.472+05:302011-04-18T23:41:58.472+05:30Hello,
I was doing research on exactly the same s...Hello,<br /><br />I was doing research on exactly the same subject not long ago (see e.g. http://www.warski.org/blog/?p=291) looking for a good way to replace the DI as it is known from Java.<br /><br />Unfortunately both solutions have problems:<br />Cake pattern:<br />* not possible to parametrize my system with a component implementation (in case there are a lot of components, creating two assemblies can lead to lots of code duplication)<br />* self-types are not inherited, if I extend a component trait e.g. to configure it (if it provides some abstract vals) the self-types need to be repeated<br />* no control over initialization order (which can lead to NPEs during assembly construction)<br /><br />Only functions:<br />* no auto-wiring - the functions have to be applied to the implementations - as can be seen in your example, you have to provide the repository impl three times<br />* every function needs to have all dependencies enumerated - instead of specifying the dependencies once<br />* the dependencies are expressed in the interface, not the implementation<br /><br />I guess the second approach is better (by looking at the list of problems, for example), however it doesn't quite seen to be the "scala" way. <br /><br />Do you maybe have some experiences in resolving the above problems?<br /><br />Regards,<br />Adam WarskiAdam Warskihttps://www.blogger.com/profile/04535036247623614805noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-57291638971189223352011-03-15T18:06:26.679+05:302011-03-15T18:06:26.679+05:30Thanks for making that comparison
Excellent postThanks for making that comparison<br />Excellent postP&C insurance softwarehttp://www.comtecglobal.com/products/policyadministration.htmnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-86148143237801977842011-03-03T22:08:33.724+05:302011-03-03T22:08:33.724+05:30Thanks Debasish, very informative as usual.
@onof...Thanks Debasish, very informative as usual.<br /><br />@onof: I personally consider wiring in dependencies at load time (ala Spring xml) extremely harmful. The large a spring app grows, the larger the context(s) become, and the longer it takes for the app to load. When there's something in the xml wiring that causes a runtime error, it is a pain to hunt down. On the other hand, with a method like this, or even using a container like guice, the dependencies are statically known, and therefore proven at compile time. Huge win.<br /><br />The only potential issue I see with a container-less approach like this is that you don't get lifecycle control over the dependencies.Unknownhttps://www.blogger.com/profile/09320660220806913377noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-21392583815358171532011-03-02T17:41:21.464+05:302011-03-02T17:41:21.464+05:30I found very interesting this post, especially the...I found very interesting this post, especially the Dependency Injection part. It's very elegant and useful, but a container is still needed IMO, because, with that approach you won't be able to inject dependencies at load-time, with a configuration file, for example.onofhttps://www.blogger.com/profile/12603742696104727799noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-63080685073213061722011-03-02T13:37:09.246+05:302011-03-02T13:37:09.246+05:30Two points:
a) If you use in the OO-style the ord...Two points:<br /><br />a) If you use in the OO-style the ordinary constructor based DI than you immidiately see the <br />similarity to the FP-style:<br /> <br /> TradeServiceImpl(val tradeRepository:TradeRepository) {}<br /> <br /> val redisRep = new RedisTradeRepositoryImpl(....);<br /> val fetchTrade_c = new TradeServiceImpl(redisRep).fechtTrade(_,_);<br /> val updateTrade_c = new TradeServiceImpl(redisRep).updateTrade_c(_,_);<br /><br />The similarity would be even clearer if scala would support full straight currying.<br /><br />b) A service-layer seldom has just three methods/functions like in the example. It generally has tens or even hundreds and<br />than the FP approach used here becomes very typing-intensive (und hard to maintain). Depending on the FP language there are<br />different nice solutions to that.<br /><br />Generally I can only recommend anyone who wants to do "more functional" in scala to take a deeper look at lisp (clojure), haskell or an ML<br />dialect (ie on the JVM the yeti language). When you are restricted to full functional-programming you just learn better <br />where it is good and how things can be done. And knowing this will help a lot to use the powerful features of scala much better instead of getting lost in them.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-45824648602498271972011-03-02T07:04:14.317+05:302011-03-02T07:04:14.317+05:30Functional approach is interesting. The only thing...Functional approach is interesting. The only thing I don't like is the funny names for curried functions with "_c" at the end. I wish it were possible to overwrite/"reuse" original name.<br /><br />val fetchTrade = fetchTrade(new TradeRepositoryRedis)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-23733815195126919452011-03-02T01:45:21.056+05:302011-03-02T01:45:21.056+05:30Thanks for the great posts (and all the others esp...Thanks for the great posts (and all the others especially on scalaz)<br /><br />However regarding dependency injection in the OO way I do not realy get what the advantage of the cake-pattern is compared to a plain constructor injection.<br /><br />Why do you have components? Why not just ie TradeServiceImpl(tradeRepository:TradeRepository) extends TradeServiceImpl {..} and than inject the dependency via the constructor like you would do in Java? That seems for the OO style much simpler and direct with less code.chrisichrishttps://www.blogger.com/profile/16109664152420254372noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-34074238483224677192011-03-01T22:04:41.033+05:302011-03-01T22:04:41.033+05:30Hi Justin -
In case it helps, I have done some bl...Hi Justin -<br /><br />In case it helps, I have done some blog posts on scalaz and its practical implications in domain modeling. Feel free to have a look at http://debasishg.blogspot.com/search/label/scalaz ..Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-3065718451823253712011-03-01T21:50:46.121+05:302011-03-01T21:50:46.121+05:30Thanks for the great write up, I've been explo...Thanks for the great write up, I've been exploring Scala composition patterns for the last few weeks and I'm excited by how powerful the language is.<br /><br />In addition to the patterns you describe I've found that the lift web framework is using the service locator pattern as an alternative to dependency injection. The service locator pattern allows for dynamic interchange of implementations at runtime.<br /><br />The lift implementation is described here:<br />http://simply.liftweb.net/index-8.2.htmlDavid Holbrookhttps://www.blogger.com/profile/06286826115964427892noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-16702779105117531932011-03-01T19:51:51.417+05:302011-03-01T19:51:51.417+05:30Very nice. Last September we had Jason Zaugg pres...Very nice. Last September we had Jason Zaugg present scalaz at New York Scala Enthusiasts. I had not taken the leap far enough into FP to start using scalaz, but now I see a very practical reason to do so.Dustin Ted Whitneyhttps://www.blogger.com/profile/17414601526967838823noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-65297678196982808312011-03-01T15:30:40.832+05:302011-03-01T15:30:40.832+05:30This is a nice comparative of each approach Debasi...This is a nice comparative of each approach Debasish - thanks for posting it :-)Timothy Perretthttps://www.blogger.com/profile/00665398127346771568noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-56675014664681163062011-03-01T13:10:13.664+05:302011-03-01T13:10:13.664+05:30Eric -
Agreed. The main focus of the article was ...Eric -<br /><br />Agreed. The main focus of the article was not composability. I wanted to discuss the virtues of Scala as a multi-paradigm language - OO and functional. And how a typical problem can be solved using either OO or FP in the language.<br /><br />But you are correct on the Unit part. Here I was considering "write" only as a side-effect. In case u missed it, I discuss composability of domain models in another post which I wrote some time back .. http://debasishg.blogspot.com/2010/12/composable-domain-models-using-scalaz.htmlAnonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-26636531591921194922011-03-01T13:00:49.895+05:302011-03-01T13:00:49.895+05:30I think we can get even better composability (in b...I think we can get even better composability (in both approaches) if the write method also returns a Trade instead of Unit. <br /><br />This is especially useful because you can get a Trade object with a "fresh" identifier and directly call another function on that object.<br /><br />This is why I came to consider that a method returning Unit should get a warning!Erichttps://www.blogger.com/profile/16484514586929815703noreply@blogger.com