3 ms·

Angular's dependency injection is still a matter of discussion and a lot of people are not completely happen with it. It'll also be made into something differen

Angular's dependency injection is still a matter of discussion and a lot of people are not completely happen with it. It'll also be made into something different for angular 2.0. Still, besides that: DRY is IMO not about these 2 lines that you've refactored away here. It's about whole functions/classes that have similar functionality where you're repeating yourself. Therefore, this would be a micro-optimisation with negative results on impact on performance most likely (since there's more overhead)

sanderjd 12y ago
The point of DRY is to reduce the types of errors that repetition lends itself to. A very common member of that class of errors is "I should have repeated something, but I didn't". It is pretty easy to run into that error with Angular's injection - you can forget to add either the string or the argument, or (worse) you can get the order wrong. Eliminating the repetition fixes that class of errors, so I think it's well within the realm of "what DRY is about".
- mcv 12y ago
  I ran into this exact thing just a few days ago. I added a dependency to an existing controller, and it threw an error because I'd only added the dependency in one place instead of both. This is absolutely one of the things that DRY is about.
- bilalq 12y ago
  I can see Classy adding value, but repetition with dependency injection is a solved problem if you use ngmin[1]. [1]: https://github.com/btford/ngmin https://github.com/btford/ngmin
  - sanderjd 12y ago
    I disagree that ngmin is a full solution to the problem. It is a good and very helpful tool, but it's a hack and a pretty leaky one - I think it's often less of a hassle to just write all the explicit injection syntax myself than to fiddle with formatting to get ngmin to work and track down issues when it doesn't. Classy's solution seems much nicer to me.
    - Cthulhu_ 12y ago
      I have no idea what you're talking about; I've never had any issues with ngmin or angular's default (i.e. non-array / string) injection methods.
      - sanderjd 12y ago
        I guess your mileage may vary, but in my experience, it isn't difficult to write reasonable code that ngmin fails to handle properly, and it's difficult to debug when it happens. It seems the best thing to do is to start with ngmin from the get-go and adopt a style guide that works with it. But I like the idea of a library that abstracts it away altogether.

sanderjd 12y ago

The point of DRY is to reduce the types of errors that repetition lends itself to. A very common member of that class of errors is "I should have repeated something, but I didn't". It is pretty easy to run into that error with Angular's injection - you can forget to add either the string or the argument, or (worse) you can get the order wrong. Eliminating the repetition fixes that class of errors, so I think it's well within the realm of "what DRY is about".

mcv 12y ago
I ran into this exact thing just a few days ago. I added a dependency to an existing controller, and it threw an error because I'd only added the dependency in one place instead of both. This is absolutely one of the things that DRY is about.
bilalq 12y ago
I can see Classy adding value, but repetition with dependency injection is a solved problem if you use ngmin[1]. [1]: https://github.com/btford/ngmin https://github.com/btford/ngmin
- sanderjd 12y ago
  I disagree that ngmin is a full solution to the problem. It is a good and very helpful tool, but it's a hack and a pretty leaky one - I think it's often less of a hassle to just write all the explicit injection syntax myself than to fiddle with formatting to get ngmin to work and track down issues when it doesn't. Classy's solution seems much nicer to me.
  - Cthulhu_ 12y ago
    I have no idea what you're talking about; I've never had any issues with ngmin or angular's default (i.e. non-array / string) injection methods.
    - sanderjd 12y ago
      I guess your mileage may vary, but in my experience, it isn't difficult to write reasonable code that ngmin fails to handle properly, and it's difficult to debug when it happens. It seems the best thing to do is to start with ngmin from the get-go and adopt a style guide that works with it. But I like the idea of a library that abstracts it away altogether.