--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/1b04ceb4-1458-46f0-88e0-dd5a07667d28%40googlegroups.com.
My issue with it is: using DI seems very complicate to do and explain to your friends if they does not come from Java Enterprice world. I'm no a full Java programmer, never in my life use Spring or anything, my background was in languages like python, ruby, etc, and Scala (only playing with language befor PlayFramework). When I listended about Play years ago that was like "oh, cool, a powerful rails in Scala!", but now it feels too complicate as old Java World.
On Fri, Apr 22, 2016 at 10:38 AM, Daniel Sanchez <anonim...@gmail.com> wrote:My issue with it is: using DI seems very complicate to do and explain to your friends if they does not come from Java Enterprice world. I'm no a full Java programmer, never in my life use Spring or anything, my background was in languages like python, ruby, etc, and Scala (only playing with language befor PlayFramework). When I listended about Play years ago that was like "oh, cool, a powerful rails in Scala!", but now it feels too complicate as old Java World.What do you find complicated about dependency injection?
There are certainly ways to use DI frameworks in a more confusing/complicated way, but if you're sticking with simple constructor injection I think it makes things easier, at least as compared to global state. It's much easier to break apart your dependencies and properly unit test them.I don't think it's fair to suggest that DI is an "enterprise Java" thing. Actually, I'd say DI provides a lot more value when it comes to large-scale consumer applications than enterprise apps, just because the scale of those apps means testability and modularity are even more important. Most of the developers I've worked with in the past were not from the enterprise Java world, and they easily were able to understand DI and why it is useful. The issue is that a lot of developers just don't have the prior experience.--
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAA%3D11HxZvuJH8juzN_p7tVLPVnihUT871dYu9Y%2B6Vss7QGhUAg%40mail.gmail.com.
To be clear, I think the so-called "compile-time DI" API is designed excellently. But the fact that it's called that (rather than "using parameters" or just "no DI" -- no need to contrast with outdated API), and is a second-class citizen (no activator template!!!) is extremely annoying, and probably turns away (or off) a lot of the more seasoned Scala developers.
To be clear, I think the so-called "compile-time DI" API is designed excellently. But the fact that it's called that (rather than "using parameters" or just "no DI" -- no need to contrast with outdated API), and is a second-class citizen (no activator template!!!) is extremely annoying, and probably turns away (or off) a lot of the more seasoned Scala developers.I'm going to clean up the tutorials section with updated examples. There are (core team maintained) two compile time DI templates:
I think contributors should be able to review and commit PRs to them as well, if I understand Github's new rights pages correctly...Will.
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAJmgB61RzyGwzQD75e8VxcXNT3-DyOw4MXjcjBwqapBYic%3D%3D2Q%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/d38e0534-a436-4680-a37a-5a46bcde68c2%40googlegroups.com.
Also I don't think core Scala teams have rejected that beauty and elegance Scala bring to all of us. Typesafe rebranding, DI in Play, Java-first in Lagom - all these signs are signs of some internal reformatting, and the most obvious thought comes to me the reformatting is forced by lack of background support in "clean Scala world". Probably we must accept the reality :)
Ideally Play should not have much of an opinion on which kind of dependency injection you use, and that's something we're working more on now and for the 2.6 release (in which Guice support will likely be split out from core). As Will said, we want to keep improving our documentation and helpers for people who want to use a pure Scala "compile-time DI" approach. The main issue is documentation (and sample projects), though.
We need to make sure our documentation makes sense for both kinds of dependency injection, since a lot of what we have so far assumes Guice.The runtime DI approach affords a lot of flexibility you can't get with compile-time DI,
and lets us automatically discover modules without forcing the user to provide explicit bindings.
So we felt it was consistent with Play's philosophy to provide really good integration with at least one runtime DI framework, and make sure everything "just works" from the start. But I can see how this also might be too much magic for newcomers.
Perhaps if the user had to explicitly configure it when you set up your project, and the behavior was obviously documented, that would make it more obvious what is going on.Andrew, I'm not sure what you mean by "internal reformatting".
The choice to release the Lagom API first in Java and the Lightbend rename didn't really have anything to do with Scala. The rename was more aimed at Typesafe's customers, where many of the decision-makers don't assign special significance to the name "Typesafe", and releasing the Lagom Java API first was done because that's where we thought the need was greatest. I'm not speaking for Lightbend in any official capacity here though.
Adding DI support in Play was done because a lot of people were asking for it and complaining about it,
and we thought it was necessary to get rid of global state.
It was really hard to build and properly test a large (or even small) app in Play using dependency injection.
I tried it back in the Play 2.1 days, and there were a lot of hacks we had to do to get around Play's global state. That said, we've always wanted to make sure the DI support is not bound to any one framework or library.
On Mon, Apr 25, 2016 at 12:28 PM, Andrew Gaydenko <andrew....@gmail.com> wrote:--
nafg,
I feel the same way.
Also I don't think core Scala teams have rejected that beauty and elegance Scala bring to all of us. Typesafe rebranding, DI in Play, Java-first in Lagom - all these signs are signs of some internal reformatting, and the most obvious thought comes to me the reformatting is forced by lack of background support in "clean Scala world". Probably we must accept the reality :)
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/d38e0534-a436-4680-a37a-5a46bcde68c2%40googlegroups.com.----
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAA%3D11Hyfa%3D6Ai9msbYJT5-H9_RsEAg_v%3D-gvKrwaDyxAGaivUQ%40mail.gmail.com.
Also I don't think core Scala teams have rejected that beauty and elegance Scala bring to all of us. Typesafe rebranding, DI in Play, Java-first in Lagom - all these signs are signs of some internal reformatting, and the most obvious thought comes to me the reformatting is forced by lack of background support in "clean Scala world". Probably we must accept the reality :)We're not all Scala programmers. A big part of the Play users do Java, and not Scala, for a lot of reasons. Play should support both camps, no just Java, not just Scala.
And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.
And while it's not always pretty, and sometimes really ugly, it's just what reality is today. Yes, Java DI has some serious limitation, and the Scala way is much better, ditching the Java camp is not really an option I think.
Igmar
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/e406c876-1e47-4d22-8335-d77c895e2eb4%40googlegroups.com.
Also I don't think core Scala teams have rejected that beauty and elegance Scala bring to all of us. Typesafe rebranding, DI in Play, Java-first in Lagom - all these signs are signs of some internal reformatting, and the most obvious thought comes to me the reformatting is forced by lack of background support in "clean Scala world". Probably we must accept the reality :)We're not all Scala programmers. A big part of the Play users do Java, and not Scala, for a lot of reasons. Play should support both camps, no just Java, not just Scala.I have no problem with that. I think the Java documentation should prefer guice, or whatever Java devs prefer. However in Scala-land, it's not idiomatic.
And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.I don't think it's hard to learn. But one of the great things that I've found about Scala making magic unnecessary, is that things become much more predictable, and thus finding bugs takes much shorter. I don't know if that holds in the question of guice vs. explicit parameter passing, but I'd rather avoid exceptions, even if only for the slippery slope argument.
And while it's not always pretty, and sometimes really ugly, it's just what reality is today. Yes, Java DI has some serious limitation, and the Scala way is much better, ditching the Java camp is not really an option I think.Absolutely, no one is suggesting that.
Greg,
Do you mean Scala language doesn't allow to avoid Play's global state without using this or that alien framework?
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/780670bd-5771-4ec1-8da0-54f8f6c46530%40googlegroups.com.
And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.I don't think it's hard to learn. But one of the great things that I've found about Scala making magic unnecessary, is that things become much more predictable, and thus finding bugs takes much shorter. I don't know if that holds in the question of guice vs. explicit parameter passing, but I'd rather avoid exceptions, even if only for the slippery slope argument.I actually prefer getting them. And no, Java doesn't have the fancy Scala stuff for the bit extra.
And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.I don't think it's hard to learn. But one of the great things that I've found about Scala making magic unnecessary, is that things become much more predictable, and thus finding bugs takes much shorter. I don't know if that holds in the question of guice vs. explicit parameter passing, but I'd rather avoid exceptions, even if only for the slippery slope argument.I actually prefer getting them. And no, Java doesn't have the fancy Scala stuff for the bit extra.
And while it's not always pretty, and sometimes really ugly, it's just what reality is today. Yes, Java DI has some serious limitation, and the Scala way is much better, ditching the Java camp is not really an option I think.Absolutely, no one is suggesting that.<rant>To be honest, I rather have Play ditch SBT. If you're talking about magic, SBT gives it all to you. Fighting the magic right now :(</rant>
Igmar--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/24824262-c218-4eac-bb27-bcfd445e9d2e%40googlegroups.com.
--
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/CAA%3D11HzyH1%3D%2BO2hkp1h405EC9iW6puQrK1HpvZO5QFp-fyat8g%40mail.gmail.com.
I used to be in favor of the cake pattern (or variants of it) but after seeing a large project that used Guice, only through the javax.inject.* packages, I'm fully onboard with JSR-330.Yes, there's an occasional exception, but I think I prefer that over the discipline required to keep the cake pattern sane with large teams.
On Tuesday, April 26, 2016 at 9:24:20 PM UTC-6, Greg Methvin wrote:On Tue, Apr 26, 2016 at 2:31 PM, Igmar Palsenberg <ig...@palsenberg.com> wrote:--And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.I don't think it's hard to learn. But one of the great things that I've found about Scala making magic unnecessary, is that things become much more predictable, and thus finding bugs takes much shorter. I don't know if that holds in the question of guice vs. explicit parameter passing, but I'd rather avoid exceptions, even if only for the slippery slope argument.I actually prefer getting them. And no, Java doesn't have the fancy Scala stuff for the bit extra.Exceptions are fine when they actually represent an exceptional (error) case, especially if they prevent your possibly broken or misconfigured application from starting.While I agree in a lot of cases the manual Scala code is easier to understand than Guice, there are a few cases where Guice will provide a more useful error than manual wiring. Think about what happens when you accidentally introduce a circular dependency. The equivalent Guice code will error when creating the injector, which means your application won't start at all (usually a good thing). Using manual wiring your app still starts and throws an error later.Another situation where I like Guice more is when binding eager singletons. lazy vals are the preferred way to declare dependencies using the thin cake pattern, but you have to explicitly call them to make sure they're initialized on startup; Guice handles this for you automatically.I'm not arguing for either approach here. I'm just saying each approach has its own pros and cons that you should be aware of. I really like the simplicity and elegance of the pure Scala approach, and that's what I've been using recently, but I also understand what's possible with Guice and runtime DI in general.
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/bc7708fb-b800-4275-ae97-a082db5f9401%40googlegroups.com.
On Tue, Apr 26, 2016, 5:31 PM Igmar Palsenberg <ig...@palsenberg.com> wrote:And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.I don't think it's hard to learn. But one of the great things that I've found about Scala making magic unnecessary, is that things become much more predictable, and thus finding bugs takes much shorter. I don't know if that holds in the question of guice vs. explicit parameter passing, but I'd rather avoid exceptions, even if only for the slippery slope argument.I actually prefer getting them. And no, Java doesn't have the fancy Scala stuff for the bit extra.I was afraid that misunderstanding would happen... :)What I meant is, I'd prefer not to make exceptions to the rule of "no magic." I didn't mean avoiding throwing runtime exceptions. Although of course that's related, because often magic as opposed to language feature means runtime error rather than compile-time error.
And while it's not always pretty, and sometimes really ugly, it's just what reality is today. Yes, Java DI has some serious limitation, and the Scala way is much better, ditching the Java camp is not really an option I think.Absolutely, no one is suggesting that.<rant>To be honest, I rather have Play ditch SBT. If you're talking about magic, SBT gives it all to you. Fighting the magic right now :(</rant>:)A few comments about SBT:1. I don't think anything in Play depends on SBT other than the SBT plugin. Granted, most of the user experience of developing in Play is provided by the plugin, and working without it is not really documented or practical. The point is that it's possible for someone to develop the equivalent of the SBT plugin (at last the parts that don't require a feature unique to SBT) standalone or for some other build tool. In fact I believe that a groovy or maven integration has been done by someone.
2. While there are decisions SBT made that many would disagree with, and that's frustrating, I think SBT is far better than any other build tool.
3. If you're expecting SBT to just be a Scala version of some other build tool, you will be very disappointed. SBT has to be understood for what it is. It's an original approach to solving the problem. James Roper has a good set of blog posts explaining what SBT really is (don't have the link at the moment).
4. Keep an eye on Christopher Vogt's CBT.
Op donderdag 28 april 2016 09:02:00 UTC+2 schreef nafg:On Tue, Apr 26, 2016, 5:31 PM Igmar Palsenberg <ig...@palsenberg.com> wrote:And to be blunt : Java DI isn't that hard. Really, I come from a C / C++ background, and I picked that up in < 3 months, including learning Java.I don't think it's hard to learn. But one of the great things that I've found about Scala making magic unnecessary, is that things become much more predictable, and thus finding bugs takes much shorter. I don't know if that holds in the question of guice vs. explicit parameter passing, but I'd rather avoid exceptions, even if only for the slippery slope argument.I actually prefer getting them. And no, Java doesn't have the fancy Scala stuff for the bit extra.I was afraid that misunderstanding would happen... :)What I meant is, I'd prefer not to make exceptions to the rule of "no magic." I didn't mean avoiding throwing runtime exceptions. Although of course that's related, because often magic as opposed to language feature means runtime error rather than compile-time error.Play is pretty much without magic if you ask me. Only some magic when you use Ebeans on Java, but for the rest, we didn't have much suprises when it comes to this. We also run some (large) Play 1.2 apps, and that's a whole different story.
And while it's not always pretty, and sometimes really ugly, it's just what reality is today. Yes, Java DI has some serious limitation, and the Scala way is much better, ditching the Java camp is not really an option I think.Absolutely, no one is suggesting that.<rant>To be honest, I rather have Play ditch SBT. If you're talking about magic, SBT gives it all to you. Fighting the magic right now :(</rant>:)A few comments about SBT:1. I don't think anything in Play depends on SBT other than the SBT plugin. Granted, most of the user experience of developing in Play is provided by the plugin, and working without it is not really documented or practical. The point is that it's possible for someone to develop the equivalent of the SBT plugin (at last the parts that don't require a feature unique to SBT) standalone or for some other build tool. In fact I believe that a groovy or maven integration has been done by someone.My biggest problem with SBT is that without Scala knowledge, it's nearly impossible to get anything done. It usually means copy & paste code, and hope that it works. Most of the time it does, if it doesn't : Really nasty.2. While there are decisions SBT made that many would disagree with, and that's frustrating, I think SBT is far better than any other build tool.It probably is. It however has a bad habit of screwing up my Ivy cache, which needs a total wipe in that case. I have a (good) copy of the Ivy cache if it needs restoring, else it will take > 1 hour to re-download all assets.
3. If you're expecting SBT to just be a Scala version of some other build tool, you will be very disappointed. SBT has to be understood for what it is. It's an original approach to solving the problem. James Roper has a good set of blog posts explaining what SBT really is (don't have the link at the moment).I come from a cmake / gnu make world. Both I understand well. I do understand ant / maven, and I dislike XML in general. Both are usually OK for me, but on the other hand : I hardly do any fancy stuff. Different with C / C++, I usually do fancy stuff there. I hope to add SBT to that list some day :)4. Keep an eye on Christopher Vogt's CBT.I will. Thanks for the pointers !Igmar
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/5171a3af-cdbd-4e42-8cc3-a8110a014cf7%40googlegroups.com.
Dependency Injection is only one specific style of the InversionOfControl(also known as the Hollywood Principle - "Don't call us, we'll call you") pattern used to build reusable, extendable, decoupled and testable components in an object oriented software architecture. So in my opinion the term "Dependency Injection" ist a bit misused here because it's only a single solution for a common problem. As Greg pointed out in another answer, ideally Play should follow the IOC principle and then the choose of the IOC style/container should be delegated to the user. With this in mind it's regardless of whether a user used compile-time or runtime dependency injection, the service locator pattern or if the user wires the dependencies by hand inside the code.IOC is also complete language agnostic because it's a design pattern used in object oriented programming. So in every language which supports object oriented programming you will stumble over it sooner or later. So for me it's not a Java enterprise thing, it's more a how many experiences do I have in object oriented software architectures. Personally, I've learned this pattern a couple of years ago in the PHP world and I'm sure there are solutions for every object oriented language out there.Best regards,Christian
Am Freitag, 22. April 2016 19:38:32 UTC+2 schrieb Daniel Sanchez:Hello everyone.
I'm Scala programmer (in fact, I know a bit more about scala that java) and user of Play since 2.1 version 3 years ago. I did not cared about porting my code to use DI before, but with Play 2.5 and the "Deprecated Warning Wall" (DWW) due Play.current, Cache, and WS libraries, I started to make it.
I understand the reasons why Play Team want to use DI "out of the box" in the project, and yes, It is a good thing, but this becomes in a pain in projects like mine where rewrite for use DI does not look trivial.
My issue with it is: using DI seems very complicate to do and explain to your friends if they does not come from Java Enterprice world. I'm no a full Java programmer, never in my life use Spring or anything, my background was in languages like python, ruby, etc, and Scala (only playing with language befor PlayFramework). When I listended about Play years ago that was like "oh, cool, a powerful rails in Scala!", but now it feels too complicate as old Java World.
I have been fighting one week tryng to port my code, but it is hard and complicate.
I really want to know the community opinion about it.
Thanks for read!
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/b8684759-b0cc-4a07-ae74-ca28eba88dbb%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/2493a493-eab0-49a0-b4e4-6825acc2a56f%40googlegroups.com.