4 ms·
Question, is there anything decorators can do that higher order functions and higher order classes cannot already accomplish? I typically dislike decorators be
by com2kid 4y ago
Question, is there anything decorators can do that higher order functions and higher order classes cannot already accomplish?
I typically dislike decorators because they are spooky action at a distance, and whenever I look at code in a language that has decorators, the code almost becomes a DSL of sorts.
Not that HoF and HoC don't tend towards the same problems, React used to be famous for how often HoC got used in the ecosystem and the confusion that caused!
- epolanski 4y agoThe answer is obviously not since decorators still compile to higher order functions.
- recursive 4y ago"higher order class" is not a term I've heard before. I'm not sure what that could mean. Decorators are syntactic sugar for higher ordered functions. They fundamentally have the same capability, just with better ergonomics.
- zdragnar 4y agoFunctions can return new class definitions- the "class" keyword represents an expression, not a statement. As such, you could write a function that takes in as an argument a class, and return a new class definition that extends the argument you provided... Or any number of other dubious practices.
- com2kid 4y agoSorry, I meant a function that rips a class open, messes with it, and returns a new class!
- anthlax 4y agoYes - decorators are syntactically nicer :)
- jdlshore 4y agoThe EcmaScript implementation of decorators is quite nice—it’s just syntactic sugar for a higher-order function call. Much better than the spooky reflection-based approach you see in some other languages.
- ajkjk 4y agoThey're the same, but decorators encourage a programming style that is much easier to follow than HOF do. This way of using them is pretty standard in Python and it works well, imo.
- seanalltogether 4y agoMy favorite usage for decorators in java is for defining http requests, it lets you write stuff like this @GET("/users/{id}") function loadUser(id: int): Promise<User> {} @PUT("/users/{id}") function updateUser(id: int, user: User): Promise<User> {}
- imbnwa 4y agoDid't know Java had a `Promise` type
- tlarkworthy 4y agoIt has an equivalent but that code is typescript
- divs1210 4y agoI didn't know Java had a `function` keyword. That is TS, not Java. Not sure why the gp is calling it Java.
- Jcowell 4y agoThey’re not . They’re saying it allows stuff like what’s it’s Java and the decorators in the TS code is exactly what it’s like in Java.
- nobleach 4y agoThat's not Java. I believe they're demoing in Typescript a pattern they like from Java/Spring/Quarkus/Micronaut.
- imbnwa 4y agoAh yikes, read that too quickly
- topspin 4y agoCan't fathom why annotation are used for this, except maybe as a holdover from years ago when Java didn't have certain language features. Other approaches in Java are much nicer and involve zero annotations. Example (from the Spark Java microframework documentation): path("/api", () -> { before("/*", (q, a) -> log.info("Received api call")); path("/email", () -> { post("/add", EmailApi.addEmail); put("/change", EmailApi.changeEmail); delete("/remove", EmailApi.deleteEmail); }); path("/username", () -> { post("/add", UserApi.addUsername); put("/change", UserApi.changeUsername); delete("/remove", UserApi.deleteUsername); }); }); All your endpoints concisely and composibly mapped out in code, and not smeared across dozens or hundreds of methods and classes. Not an annotation in sight; just plain old Java.
- swatcoder 4y ago> almost becomes a DSL of sorts For mature projects with experienced, cohesive teams, that’s a good thing. You want a DSL that blends right in with your fully capable base language. But yeah, just like with any powerful feature, people can get excited and carried away.
- rcme 4y agoI think some people want things to be DSL-like. However, I don’t think, long-term, using a DSL-like syntax wins. Ruby was famous for abusing Ruby’s unique syntax to make everything into a DSL and it turned off newcomers. Similarly, Java’s DI frameworks meet a lot of resistance because of their heavy use of annotations. Ultimately, DSLs are separate languages. Most people don’t want to learn a new language.
- swatcoder 4y agoThe countless users of popular third-party frameworks are the opposite of a “experienced, cohesive team” so I agree with you that it can and has caused problems there.
- djur 4y agoIn my experience as someone who has worked with dozens of new Ruby developers, I think the ability to create expressive DSLs was a significant net positive. It was much more likely to be a source of excitement than something that turned newcomers off. I don't think DSLs are or were a problem for Ruby (nor do I think they count as "abusing syntax").
- spankalee 4y agoDecorators enable metaprogramming over class fields. Nothing before them has done that.
- super256 4y ago> I typically dislike decorators because they are spooky action at a distance, and whenever I look at code in a language that has decorators, the code almost becomes a DSL of sorts. Yes, decorators are not evil by themselves, but they allow people to make poor choices easier. Having to debug decorators, fiddling with order of execution + scope binding/closures when setting multiple decorators, can (not sure!) become a nightmare; depending on the code base. Or we just go straight to the hibernate spaghetti. Imagining having to use three decorators with the same name, but different functions, makes me not to want to work with this. Having worked with (old) Java EE and Jakarta code bases, I've seen decorators being abused in 300 ways and breaking ABI in 600 ways, so let's hope we stay sane this time.