new method Peer.isConnected() #38

Merged
merged 2 commits into from Apr 3, 2013

Projects

None yet

2 participants

@MatthiasLohr

This method should be used for detecting if there's an active connection to the peer server instead of usage of Peer.disconnected, because this field is used internally and with this function the behavior internally can change later without problems.

@michelle
Member
michelle commented Apr 2, 2013

I should really do this with all of the 'public' instance variables (the ones without '_' that are meant to be part of the API) on Peer and DataConnection. I will think about this some more, because if I merge in this getter for .disconnected, I'll have to consider the other ones as well, and those are some huge API changes.

Rest assured for now though, .disconnected will stay consistent despite its internal use.

@MatthiasLohr

For internal use, i see no reason why not to use variables. If you have to change the behavior of one of these variables, you are able to solve all dependent issues, because it's 'your' library.
But (in my opinion) getter methods has a longer life than variables, so external programms can rely longer to getters than an instance variable. The second advantage is the fact that you are able to insert logic if it's needed. Otherwise you have to calculate and update some variables, regardless if the value is needed or not.

For example (maybe for peerjs not important as for other network libraries) the situation if the library is in progress to connect to a server. If there is a getter method, you could block the call until the connection is established or the connect failed and you return the correct result. Otherwise MAYBE (race condition, etc) it could be possible that you return the wrong result. In some special cases (RT apps) this could be a problem.

Btw: For the first step, it would be enough to provide some simple getters for existing variables. How i said, internally you can use variables, because when a change occurs you're able to change all usages of this variable without affecting users of this library. Otherwise other people maybe have to modify their program to make it compatible with a newer version of peerjs.

@michelle
Member
michelle commented Apr 2, 2013

Yeah it's probably a good idea to slowly transition into getters. I will look into it more and see what else makes sense to transition right away.

Sent from my iPhone

On Apr 2, 2013, at 3:22 PM, Matthias Lohr notifications@github.com wrote:

For internal use, i see no reason why not to use variables. If you have to change the behavior of one of these variables, you are able to solve all dependent issues, because it's 'your' library.
But (in my opinion) getter methods has a longer life than variables, so external programms can rely longer to getters than an instance variable. The second advantage is the fact that you are able to insert logic if it's needed. Otherwise you have to calculate and update some variables, regardless if the value is needed or not.

For example (maybe for peerjs not important as for other network libraries) the situation if the library is in progress to connect to a server. If there is a getter method, you could block the call until the connection is established or the connect failed and you return the correct result. Otherwise MAYBE (race condition, etc) it could be possible that you return the wrong result. In some special cases (RT apps) this could be a problem.

Btw: For the first step, it would be enough to provide some simple getters for existing variables. How i said, internally you can use variables, because when a change occurs you're able to change all usages of this variable without affecting users of this library. Otherwise other people maybe have to modify their program to make it compatible with a newer version of peerjs.


Reply to this email directly or view it on GitHub.

@michelle michelle merged commit c0b8e0a into peers:master Apr 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment