Refactoring: Removal of collections

[jopanel]

Collections should be optional. Not all OOP frameworks utilize collections. Nor people who wan't to create a procedural script.

[shonjord]

@jopanel This PR to me makes more sense, you're just removing the collections, that's fine, because the library can still type hint using arrays 👍 .

[jopanel]

Based on my previous PR and our conversation I think this is the better way to go. Almost every occasion there is no collections class that I have been apart of in an in-house setting. However many businesses utilize symfony, laravel, magento, etc. that has a collections class. It will not be a problem to utilize a collection wrapping an array if needed by the user. If a case were to ever arise.

The objects for "new To" and such I understand will work good for debugging and validation. Standard OOP practices and such make them nice. My original concern before was that there was going to be no validation for the objects and that they were uselessly being called too. However that's not the case.

Also we must not forget category! It is super important. It helps so much to know what email got sent to what person. We send emails for: invoices, shipping confirmations, registration, reactivation, etc. It is very important to know what email got sent when I am asked by sales department "Hey Joe customer X didn't receive the Y email". Same with our marketing mass emails we send out. I can use the API to pull statistics on the category back to our backend which I do.

[thinkingserious]

Hello @jopanel,

Thanks again for the PR!

We want to show our appreciation by sending you some swag. Could you please fill out this form so we can send it to you? Thanks!

Team SendGrid DX