aatxe / irc

the irc crate – usable, async IRC for Rust
Mozilla Public License 2.0
535 stars 100 forks source link

Confusing naming. #46

Closed mpatraw closed 6 years ago

mpatraw commented 8 years ago

When looking at the client code I see irc::client::IrcServer, which confused me at first. I would expect irc::client::IrcClient. Is there a reason for this name? What will the name of the server be? irc::server::IrcClient?

retep998 commented 8 years ago

It is called IrcServer because it represents a connection to an IRC Server. On the server side I imagine there would be an IrcServer of some sort which then creates IrcClient instances as connections are accepted.

cmbrandenburg commented 7 years ago

Are there any words of persuasion that can reopen this ticket? Regardless of @retep998's rationale, this crate uses the terms “server” and “client” backwards from how most Rust crates use the terms. E.g., see popular crates such as hyper and tokio_proto. In my opinion, even if the entire world were backwards and this were the one sane crate, it makes code less readable to deviate from the idiom of naming client-side types “client” and server-side types “server.”

aatxe commented 7 years ago

I suppose I could be convinced. To me, the difference in naming is stemming from a difference in API design. In this crate, an irc::client::IrcServer represents an interface to a server. The API is designed from that perspective. You send things to the server, or receive things from the server (this last bit used to be more explicit because there was a recv function on servers). By contrast, hyper and tokio are giving you an API that "builds a client" or "builds a server."

I guess I ultimately feel that this library is too low-level to claim to be giving you a programmatic IRC client (and that a name like IrcClient would imply as much). Maybe that doesn't matter so much. I do wonder to what extent this confuses others though. I'll reopen it.

Jokler commented 7 years ago

Based on what irc::client::IrcServer represents within the API, I would not suggest using the term of IrcClient but rather IrcConnection. The reasoning for this is that as already stated the name does not represent a server or a client but rather the direct connection. A point that was raised was that this term may seem vague but I reckon it can be extended and understood from the get-go more so than the term of server which can be easily misunderstood.

Regarding the name of Client I would say it is in fact more something that a server would deal with as @aatxe has already mentioned. Server itself makes some sense that it is the server you are communicating with but precisely in that use case IrcConnectionwould fit much better.