4 ms·

>But if I were trying to solve the problem one reader sent to me as a canonical example of an OO problem, I wouldn't. Suppose you have n serial ports, each of w

>But if I were trying to solve the problem one reader sent to me as a canonical example of an OO problem, I wouldn't. Suppose you have n serial ports, each of which may speak one of k protocols, and this must be configurable at run-time. I'd just use an n-by-k array of closures to represent this. Can anyone enlighten me about this? My first thought is that n+k units of code is less than n*k, but I expect it's more subtle than that :-) What about code reuse? In OO land, it's fairly obvious to me that I could take any number of my protocols and use them across a TCP/IP connection, or carrier pigeon, or a file, but I can't see how the closure example would allow this sort of sharing. Is that the point? Only code what's necessary?

gizmo 17y ago
I suspect the n-by-k array part is a typo, an one-dimensional array of closures is all you need. I also don't think the closure approach is bad for code reuse. The closures serve just to bind the environment to the TCP-handler and UDP-handler functions. The closures themselves are probably trivial and not worth sharing, and the protocol handler functions (or closures) can be shared like any other library function.
- pvg 17y ago
  Where are you (and the OP) getting TCP and UDP from?
  - danparsonson 17y ago
    My point was that the protocols could in theory be used across connections other than serial ports.
- deleted 17y ago
  [deleted]
barrkel 17y ago
Not specific to your issue, but rather to the use of closures where OO folks would use objects. The thing is, a lot of the time you need sideband data. A simple closure isn't always enough. Perhaps you need configuration options, or you need names for diagnostics, or you need to monitor throughput statistics, etc. A closure is a clumsy interface when it's overloaded to do multiple things. You end up with some kind of variadic argument list and having to switch on the first or more arguments - you basically end up writing a method dispatch routine. So in this specific example, I would suggest that using a closure may turn out to be the wrong choice longer-term. I'd probably prefer a base class with a virtual method, and a concrete descendant which delegated the action to a closure. That way you get the succinctness of a closure when that's sufficient, but you also get the future proofness that a base class provides - you can add more functionality in the future, but without breaking previously defined implementations.
- sophacles 17y ago
  I ran into a similar problem this morning-- using python tho. There is an api with multiple decorators possible. One decorator has implications for the program execution model. Because python decorators take heavy advantage of closures, we run into a problem where external code cannot determine appropriate actions unless the decorator in question is the outermost decorator. This of course is an ugly requirement. Our ultimate solution was to create a global table about if the relevant bit of state applies to the function (based on __name__). Also an ugly hack, but keeps the api clean. :(

gizmo 17y ago

I suspect the n-by-k array part is a typo, an one-dimensional array of closures is all you need. I also don't think the closure approach is bad for code reuse. The closures serve just to bind the environment to the TCP-handler and UDP-handler functions. The closures themselves are probably trivial and not worth sharing, and the protocol handler functions (or closures) can be shared like any other library function.

pvg 17y ago
Where are you (and the OP) getting TCP and UDP from?
- danparsonson 17y ago
  My point was that the protocols could in theory be used across connections other than serial ports.
deleted 17y ago
[deleted]

barrkel 17y ago

Not specific to your issue, but rather to the use of closures where OO folks would use objects. The thing is, a lot of the time you need sideband data. A simple closure isn't always enough. Perhaps you need configuration options, or you need names for diagnostics, or you need to monitor throughput statistics, etc. A closure is a clumsy interface when it's overloaded to do multiple things. You end up with some kind of variadic argument list and having to switch on the first or more arguments - you basically end up writing a method dispatch routine. So in this specific example, I would suggest that using a closure may turn out to be the wrong choice longer-term. I'd probably prefer a base class with a virtual method, and a concrete descendant which delegated the action to a closure. That way you get the succinctness of a closure when that's sufficient, but you also get the future proofness that a base class provides - you can add more functionality in the future, but without breaking previously defined implementations.

sophacles 17y ago
I ran into a similar problem this morning-- using python tho. There is an api with multiple decorators possible. One decorator has implications for the program execution model. Because python decorators take heavy advantage of closures, we run into a problem where external code cannot determine appropriate actions unless the decorator in question is the outermost decorator. This of course is an ugly requirement. Our ultimate solution was to create a global table about if the relevant bit of state applies to the function (based on __name__). Also an ugly hack, but keeps the api clean. :(