Split in WhatsAppUpdate and WhatsAppClient

[soerenetler]

Hi,
i think it would make sense to split the WhatsApp class into a WhatsAppUpdate and WhatsAppClient class. Many of the functions lower in the file like get_location don't actually need the Client. This would make the library easier to handle. One could create a WhatsAppUpdate object from the data and call the get_location on that Only sending messages would need the WhatsAppClient object.
I would be happy to contribute to the project. Let me know what you think about this proposal.

[Kalebu]

Hi @soerenetler

I like the idea, how are we going to ensure that this update is not going to break code of people who already created it using a version with only WhatsApp class ?

[soerenetler]

@Kalebu,
I didn't think it through yet. The functions could still exist inside WhatsApp and forward with a DeprecationWarning. I think in version 0.0.6 it is still fine to introduce breaking changes.
Are there automated tests for this library?

[Kalebu]

We don't have automated testing yet but you're welcome to contribute and create a PR for it`

@soerenetler

[Kalebu]

Also regarding the breaking changes problem I think we can create a WhatsAppUpdate as a different class inherited by the WhatsApp class so that it works in both ways, making it easier to maintain without breaking any existing code base.

[soerenetler]

We don't have automated testing yet but you're welcome to contribute and create a PR for it`

@soerenetler

I just created a new PR for automated testing. #38
Looking forward to your feedback.