|
|
|
|
|
|
by thirdmunky
1448 days ago
|
|
|
How can I extend this version to multiple loggers, like the article does? Do I need to write in my application code: writeStringToFileAndWrappedSocket(w: WrappedSocket, f:File, s:String) = writeStringToFile(f,s) and writeStringToWrappedSocket(w,s)
If this is written in the library, that is 2^n combinations of file output functions - even worse than the n*m the article complains about. |
|
|
This is a feature you want. When you code you want to build things in a style that's modular like legos such that you have the ABILITY to build 2^N or more combinations. Any style of coding that restricts this ability is a detriment. Don't get confused, we're talking about the term "modularity" here. Modularity is a feature you want. Who wants a library/framework/programming language that DOESN'T give them ability to be modular or have the capability of building 2^N combinations? It's about ability not actuality.
Not every high level function needs to be implemented. Like any framework you should be given the tools to build whatever you want. If you want somewthing simpler, that's ok too. Then you wouldn't expose all the core low level functions of the library. You would expose higher level functions in your api and make the primitives private. But to build those high level functions, the way to go is to modularly construct them as I did in the example above.
Maybe they don't need logFilterWithSuffixToFileAndSocket. Then don't create it. You just need the foundational primitives such that if I wanted to create it, I CAN. And you can also expose primitive functions through the API such that users CAN too. That is the core philosophy of programming.