Support more API endpoints and reorganize measures

[u1735067]

• Reorganize measures : put them in Measure object in a Collection
• Remove the specific getters and setters, use generic ones (I don't like to copy/paste code :) ), make properties public
  • Most of the code (if not all) should be retrocompatible.
• Measure objects allows to retrieive their unit, and handle conversion
• Don't overload Collection::__construct(), use the new fromParams() instead, because overloading prevent the use of keys() for example.
  • Limitation (but was already present): added properties become unavailable on sort() for example
• Use new endpoint, handle more error code
• Allow users to use the request method
• Updated example
• Objects are JsonSerializable (for entities, only code is exported), require php>=5.4
• MeasureGroup: use timezone from MeasureGroupCollection

[Zn4rK]

Nice!

I'll take a look ASAP, but it seems like you've done some extensive work here - awesome!

[u1735067]

The only strong opinion I have is that we shouldn't use magic overloading if we don't need to, and I like the getters. The strongest reason for it, is that together with PHPDoc it becomes much more easy to work with and it increases the readability when you don't have to figure out what the magic method actually does.

I understand that. However, my "IDE" is Codiad, so I don't have autocompletion/whateverItIs to create the getters. I'm not going to create them by hand. The get() and call() I put are mostly for retrocompatibility, IMO, properties should be public (is there a reason to prevent "users" (developers) to access them ?), documented, and used directly.

We are also missing PHPDoc one a few places, and that needs to be addressed.

Yes, it's needed.

This library follows PSR-FIG PSR-2, and if you can make changes that reflect that I will gladly merge this!

Is there something else than what you mentionned that should be changed for compliance ?

• About the arrays, maybe an IDE can handle this ?
• raw debug junk : maybe this could be placed under a debug tag / constant ?
• missing braces: I was lazy, I may add them one day
• missing doc : same (they're pretty obvious though)

Btw, what is the "Jebaited" thing ?

[Zn4rK]

I have no idea about the jebaited thing. A friend tried to be funny - I think. Sorry about that.

[Zn4rK]

Normally, I wouldn't directly disagree with you. I would probably set them at protected and have the developer extend and replace the class if needed anyway though. With the dependency injection in Laravel it's possible.

But since our data is coming from an external API we need to be sure that it hasn't changed by some third party library or that another developer in our project has taken a shortcut or made a logic error, or something else. With non-public properties and getters we can be sure that nothing has happened to our data.

Other than that, it's just a preference.

[Zn4rK]

How about this? I'll merge this into development, and I'll try to go over the code and add the getters...

[Zn4rK]

I like the debug constant idea!

[u1735067]

Fixed the variable errors & the noted braces. Array notation, visibility and getters are left to you (they shouldn't prevent this version from working). The project I worked on planned to use this lib, but the project is no longer alive :/ I hope the changes will be useful to someone else though !

[Zn4rK]

Thank you for this! And I'm sorry to hear about your project... Merging it into development to give me time to adjust the code to my likings :)