What do you think about library, called "Rust TcpSever"? What new features should I add to it?
Father, forgive them, for they do not know what they are doing.
Why would you even do this if you have a struct CleanServer
that could hold the TcpListener
?
So that the user can install TcpListener from anywhere. Is the problem with this approach, or is it the fact that unsafe is used? If the problem is unsafe, I can move this variable to Mutex using lazy_static.
That doesn't make any sense. What does this have to do with installation?
If the struct only contains the TCP listener, you may even implement From<TcpListener> for CleanServer
, so that the user can .into()
any TcpListener
anywhere at any point in their code.
That is?
TcpListener::bind("127.0.0.1:80").unwrap().into().launch(4);
I would not use unwrap()
in production code ever, but yes, in principle, that's what I was talking about.
Okay, then I’ll do that, it will allow me to shorten and streamline some of the code. What would you use instead of unwrap() ?
Proper error handling of the returned Result
or a call to expect()
with an appropriate message containing the reasoning why you assume that the error can never occur.
Unfortunately, due to the use of trait, it is not possible to pass CleanServer as &self, which would make it look like:
Server::launch(TcpListener("127.0.0.1:80").expect("error").into(), 4);
But then why create such a structure? If you can go back to the old implementation and just do it like this:
Server::launch(TcpListener("127.0.0.1:80").expect("error"), 4);
or
Server::launch(
TcpListener("127.0.0.1:80").expect("error"),
ThreadPool::new(4)
);
So I'll just return the old implementation. And which one do you think looks better?
You can adjust the CleanSever
[sic!] trait to
- Take the
TcpListener
as additional argument inlaunch()
- Make
launch
take&self
.
Can you post an example? I don't fully understand what you mean...
#1 is basically your last example from above.