▲ 99 ▼ Why make it complicated? (lemmy.ml) submitted 1 year ago by HiddenLayer555@lemmy.ml to c/programmerhumor@lemmy.ml 51 comments fedilink hide all child comments Made with KolourPaint and screenshots from Kate (with the GitHub theme).
[–] phlegmy@sh.itjust.works 3 points 1 year ago (4 children) If you actually use code like this you're insane. permalink fedilink source parent hideshow 4 child comments replies: [–] sph@lemmy.world 4 points 1 year ago* (2 children) This obviously just illustrates a point, but callbacks and decorators are not uncommon. And iterators are exactly like that: type ( Seq[V any] func(yield func(V) bool) Seq2[K, V any] func(yield func(K, V) bool) ) Which is very readable. permalink fedilink source parent hideshow 2 child comments replies: [–] phlegmy@sh.itjust.works 3 points 1 year ago (1 child) Callbacks and decorators are fine, but callbacks/decorators to a function which itself takes a function pointer and returns another function pointer are crazy. I've thankfully never had to use recursive callbacks or decorators, but it seems like it could very quickly become difficult to keep track of. permalink fedilink source parent hideshow 1 child comment replies: [–] sph@lemmy.world 3 points 1 year ago* I don't think it's that uncommon. Let's say you have a function that handles a request. A common use case is to add permission checks before applying that function. You can write a generic permission check a bit like this: func NeedsPermission(f func(Request) (Response, error), perm string) func(Request) (Response, error) { return func(r Request) (Response, error) { if !check(r, perm) { return nil, NewPermError(perm) } return f(r) } } // elsewhere Bar := NeedsPermission(Foo, "superman") This would allow you to separate the permission check logic from the business logic. Though to be fair, in Go they prefer to keep things as simple as possible but it's just to illustrate that these concepts are not that alien. permalink fedilink source parent [–] ThirdConsul@lemmy.ml 2 points 1 year ago Wait until you learn about transducers (Are they in Go? If not natively, someone definitely ported them) and the abominations fp people code with them. permalink fedilink source parent
[–] sph@lemmy.world 4 points 1 year ago* (2 children) This obviously just illustrates a point, but callbacks and decorators are not uncommon. And iterators are exactly like that: type ( Seq[V any] func(yield func(V) bool) Seq2[K, V any] func(yield func(K, V) bool) ) Which is very readable. permalink fedilink source parent hideshow 2 child comments replies: [–] phlegmy@sh.itjust.works 3 points 1 year ago (1 child) Callbacks and decorators are fine, but callbacks/decorators to a function which itself takes a function pointer and returns another function pointer are crazy. I've thankfully never had to use recursive callbacks or decorators, but it seems like it could very quickly become difficult to keep track of. permalink fedilink source parent hideshow 1 child comment replies: [–] sph@lemmy.world 3 points 1 year ago* I don't think it's that uncommon. Let's say you have a function that handles a request. A common use case is to add permission checks before applying that function. You can write a generic permission check a bit like this: func NeedsPermission(f func(Request) (Response, error), perm string) func(Request) (Response, error) { return func(r Request) (Response, error) { if !check(r, perm) { return nil, NewPermError(perm) } return f(r) } } // elsewhere Bar := NeedsPermission(Foo, "superman") This would allow you to separate the permission check logic from the business logic. Though to be fair, in Go they prefer to keep things as simple as possible but it's just to illustrate that these concepts are not that alien. permalink fedilink source parent
[–] phlegmy@sh.itjust.works 3 points 1 year ago (1 child) Callbacks and decorators are fine, but callbacks/decorators to a function which itself takes a function pointer and returns another function pointer are crazy. I've thankfully never had to use recursive callbacks or decorators, but it seems like it could very quickly become difficult to keep track of. permalink fedilink source parent hideshow 1 child comment replies: [–] sph@lemmy.world 3 points 1 year ago* I don't think it's that uncommon. Let's say you have a function that handles a request. A common use case is to add permission checks before applying that function. You can write a generic permission check a bit like this: func NeedsPermission(f func(Request) (Response, error), perm string) func(Request) (Response, error) { return func(r Request) (Response, error) { if !check(r, perm) { return nil, NewPermError(perm) } return f(r) } } // elsewhere Bar := NeedsPermission(Foo, "superman") This would allow you to separate the permission check logic from the business logic. Though to be fair, in Go they prefer to keep things as simple as possible but it's just to illustrate that these concepts are not that alien. permalink fedilink source parent
[–] sph@lemmy.world 3 points 1 year ago* I don't think it's that uncommon. Let's say you have a function that handles a request. A common use case is to add permission checks before applying that function. You can write a generic permission check a bit like this: func NeedsPermission(f func(Request) (Response, error), perm string) func(Request) (Response, error) { return func(r Request) (Response, error) { if !check(r, perm) { return nil, NewPermError(perm) } return f(r) } } // elsewhere Bar := NeedsPermission(Foo, "superman") This would allow you to separate the permission check logic from the business logic. Though to be fair, in Go they prefer to keep things as simple as possible but it's just to illustrate that these concepts are not that alien. permalink fedilink source parent
[–] ThirdConsul@lemmy.ml 2 points 1 year ago Wait until you learn about transducers (Are they in Go? If not natively, someone definitely ported them) and the abominations fp people code with them. permalink fedilink source parent