4 ms·

I think people would take issue with the more explicit forms of function annotation being the only option, for the simple reason that they're a bit verbose

by caitp 13y ago

I think people would take issue with the more explicit forms of function annotation being the __only__ option, for the simple reason that they're a bit verbose and ugly. It's very nice for people to be able to just write code that appears to magically work, without any extra noise. That said, the dependency injection system in angular.dart is a bit different, and we'll likely be learning and porting some of that back into AngularJS 2.0 over the coming months.

davexunit 13y ago
>I think people would take issue with the more explicit forms of function annotation being the __only__ option, for the simple reason that they're a bit verbose and ugly. I understand the desire to build elegant abstractions via metaprogramming, but I think is an example of metaprogramming done poorly. This particular feature was a source of confusion for me and my coworkers when we first started learning to use Angular. I think that the explicit form is the only sane way, or at least one of the possible sane ways. I'll $q.defer() to SICP to explain the principle that is being violated by the implicit form: "One detail of a procedure's implementation that should not matter to the user of the procedure is the implementer's choice of names for the procedure's formal parameters. ...This principle -- that the meaning of a procedure should be independent of the parameter names used by its author -- seems on the surface to be self-evident, but its consequences are profound." http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_%_sec_Temp_41 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#...
- michaelw 13y ago
  While I agree with what SICP says, the function in this case isn't really a function. It's not something a caller will ever invoke explicitly. It exists to provide a closure that can be initialized with the injected parameters. Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit: myModule.provider ProviderName inject $scope, $document, SomeOtherDependency { your code here } The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider. Javascript's greatest weakness is that it's native syntax is poorly suited for creating language like extensions. The result is that things like modules, imports, etc. tend to be very verbose and noisy.
  - andreypopp 13y ago
    Here you go — http://bit.ly/1ic1X49 http://bit.ly/1ic1X49
  - davexunit 13y ago
    >Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit: Well, sure. If and when JavaScript gains hygienic macros (via sweet.js or otherwise), I will like this sort of notation. However, the reality is that JavaScript doesn't have macros currently. Thus, I still dislike the magical dependency notation. >The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider. I don't see why this is bad. Several languages allow you to rename things in imported modules. The two that I can think of immediately are Python and Guile Scheme. Most of the time there is no reason to rename, but sometimes it is a good idea to rename for clarity or to avoid name clashes. This is something that you can already do via the explicit form of dependency injection.
Silhouette 13y ago
It's very nice for people to be able to just write code that appears to magically work, without any extra noise. Unfortunately, it isn't always so nice for the guy who has to read it three years later and figure out what's going on. Sometimes there is a fine line between useful tools that reduce boilerplate and leaky abstractions that hide important details you're often going to need anyway. I suspect some of the features in Angular today will prove to be on the wrong side of that line, though to be fair it's hardly the only JS framework from the recent crop where that concern applies.
- caitp 13y ago
  The 1.x injector is not a very difficult pattern to understand, so if you're working with Angular you should pick up on it quickly. However, for production apps, you're probably not using "magic" function annotation, at least not without the help of ngmin or a similar tool. It's just a nice way to quickly write demonstrations and explain code. Arguably, the explicit annotations would not really inform you any better than implicit annotation, if you were unfamiliar with the framework. So, I agree that explicit annotation is important, but I think the "magic" annotation also makes the framework a bit more accessible to new comers, and is also very handy for producing small demos, reproductions, or other small apps. The fact that we can offer the choice here is great. A little bit of experience with the framework and all this stuff becomes pretty much second nature. I expect Ember or Knockout would be similar in that regard. Basically, 1) understand the fundamentals of your framework. 2) use the right tools/methods for the right job. You can certainly write maintainable and understandable apps using all of the annotation styles. At least, in my opinion.

I think people would take issue with the more explicit forms of function annotation being the __only__ option, for the simple reason that they're a bit verbose

by caitp 13y ago

davexunit 13y ago

>I think people would take issue with the more explicit forms of function annotation being the __only__ option, for the simple reason that they're a bit verbose and ugly. I understand the desire to build elegant abstractions via metaprogramming, but I think is an example of metaprogramming done poorly. This particular feature was a source of confusion for me and my coworkers when we first started learning to use Angular. I think that the explicit form is the only sane way, or at least one of the possible sane ways. I'll $q.defer() to SICP to explain the principle that is being violated by the implicit form: "One detail of a procedure's implementation that should not matter to the user of the procedure is the implementer's choice of names for the procedure's formal parameters. ...This principle -- that the meaning of a procedure should be independent of the parameter names used by its author -- seems on the surface to be self-evident, but its consequences are profound." http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_%_sec_Temp_41 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#...

michaelw 13y ago
While I agree with what SICP says, the function in this case isn't really a function. It's not something a caller will ever invoke explicitly. It exists to provide a closure that can be initialized with the injected parameters. Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit: myModule.provider ProviderName inject $scope, $document, SomeOtherDependency { your code here } The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider. Javascript's greatest weakness is that it's native syntax is poorly suited for creating language like extensions. The result is that things like modules, imports, etc. tend to be very verbose and noisy.
- andreypopp 13y ago
  Here you go — http://bit.ly/1ic1X49 http://bit.ly/1ic1X49
- davexunit 13y ago
  >Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit: Well, sure. If and when JavaScript gains hygienic macros (via sweet.js or otherwise), I will like this sort of notation. However, the reality is that JavaScript doesn't have macros currently. Thus, I still dislike the magical dependency notation. >The last thing you'd expect is a syntax where the injected dependency names were chosen by the implementor of the provider. I don't see why this is bad. Several languages allow you to rename things in imported modules. The two that I can think of immediately are Python and Guile Scheme. Most of the time there is no reason to rename, but sometimes it is a good idea to rename for clarity or to avoid name clashes. This is something that you can already do via the explicit form of dependency injection.

Silhouette 13y ago

It's very nice for people to be able to just write code that appears to magically work, without any extra noise. Unfortunately, it isn't always so nice for the guy who has to read it three years later and figure out what's going on. Sometimes there is a fine line between useful tools that reduce boilerplate and leaky abstractions that hide important details you're often going to need anyway. I suspect some of the features in Angular today will prove to be on the wrong side of that line, though to be fair it's hardly the only JS framework from the recent crop where that concern applies.

caitp 13y ago
The 1.x injector is not a very difficult pattern to understand, so if you're working with Angular you should pick up on it quickly. However, for production apps, you're probably not using "magic" function annotation, at least not without the help of ngmin or a similar tool. It's just a nice way to quickly write demonstrations and explain code. Arguably, the explicit annotations would not really inform you any better than implicit annotation, if you were unfamiliar with the framework. So, I agree that explicit annotation is important, but I think the "magic" annotation also makes the framework a bit more accessible to new comers, and is also very handy for producing small demos, reproductions, or other small apps. The fact that we can offer the choice here is great. A little bit of experience with the framework and all this stuff becomes pretty much second nature. I expect Ember or Knockout would be similar in that regard. Basically, 1) understand the fundamentals of your framework. 2) use the right tools/methods for the right job. You can certainly write maintainable and understandable apps using all of the annotation styles. At least, in my opinion.