2010/7/4 Peter Bex <[email protected]>: > On Sun, Jul 04, 2010 at 02:59:14PM +0200, Thomas Chust wrote: > [...] >> * I think ssl-port->tcp-port should be exported from the openssl >> module. That way it would be possible for client code to call >> (port->fileno (ssl-port->tcp-port ...)) and use the result in a >> call to file-select or some other low level status inquiry that >> requires a file descriptor, which may be useful. > > Hm, good point. Should it still define ssl-addresses then? It's > redundant since user code could do (tcp-addresses (ssl-port->tcp-port p)) > manually.
Hello, maybe ssl-addresses is important enough to warrant a convenience routine. Maybe an additional ssl-port->fileno procedure would also make sense. If minimalism is a goal, exporting ssl-port->tcp-port would be sufficient, though. > [...] >> * To avoid code duplication I would consider replacing the manual >> definition of ensure-ssl-port with a use of the check-errors egg, >> ie. to write (define-check+error-type ssl-port), export >> check-ssl-port and error-ssl-port as well as ssl-port? and use >> check-ssl-port instead of ensure-ssl-port. > > I don't agree here. Using check-errors would make some sense, but would > introduce a dependency (openssl didn't require any other eggs up till now) Ok, that's a good point. > [...] > Also, why should it export the checking procedures? I don't know of any > other type or egg that has such checking procedures exported. It's only > of marginal use to openssl-using code. For completeness' sake I think *-check and *-error procedures should always be exported if they are defined and a predicate is exported. I was under the impression that most eggs do it that way, but then again not many eggs export new types with predicates anyway. This whole business of using check-errors was just a thought out of an impulse to reuse code where possible. It's not really important and the solution present in the patch is perfectly fine as well! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. _______________________________________________ Chicken-hackers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-hackers
