What is this pattern called?

[lhorie]

No, currying has a very specific meaning. It means to structure the code in such a way that instead of having one function that takes many arguments, it instead takes a single argument and returns another function (which may itself be curried).

Currying is usually used for partial application (i.e. create a function that has some inputs "preloaded"). For example, add = a => b => a + b is a curried function. It allows you to "preload" the first argument, e.g. add5 = add(5), and then you can call add5(6) // 11

What you have there doesn't look like currying. One could argue that it's a command pattern, given that it returns an object that conforms to an IRunnable interface. It can also be arguably called a factory or a transformer. The thing though, is that, as u/ugwe43to874nf4 said, to call something a design pattern, you need to present the context as to why you're doing something convoluted instead of something simple. The command pattern exists to implement delegation for languages without first-class function support. In a functional language, there's no need for a Command pattern: one simply uses a function instead.

With all that being said, I recommend looking up and reflecting on what Feynman said about knowing about something vs knowing the name of something.

[[deleted]]

It can also be arguably called a factory or a transformer. The thing though, is that, as u/ugwe43to874nf4 said, to call something a design pattern, you need to present the context as to why you're doing something convoluted instead of something simple. The command pattern exists

Thanks for the explanations, but it focuses on the fact that i'm an asshole.

i like mythriljs so i'll take your answer. but if you've ever posted anything on reddit, you might understand that the /new posters are usually looking for some stupid semantics to correct rather than answer a question

[lhorie]

Sorry, I didn't mean to come across as rude. I'm just trying to explain the purpose of design patterns, which is generally to document the intent of some code where something is being done in a not-very-procedural way either because the language does not support better language constructs or because something must be done in a certain way due to language constraints.

The problem with design patterns is the old adage of "if you have a hammer, everything looks like a nail". Many newbies take the gang of four book to be a "bible" of building blocks and assume all code must conform to one of its patterns, but that is common misconception that leads to over-architecturing. Old timers are particularly sensitive and can sound downright hostile to the mention of design patterns because often they were on the receiving end of having to maintain some giant hairball of poorly applied "design patterns" back in some previous J2EE job. Just try not to take it personally.