Use array for payload instead of an object?

[quicksketch]

Over in the PR to Project module (https://github.com/backdrop-contrib/project/pull/13) it's noted that the $payload object switched from an array to an object. I know that is the default behavior when calling json_decode() on a JSON string. Could we consider using an array in GitHub API? Reasons why I find arrays to be better to work with:

• Arrays have a shorter notation for specification (e.g. array('foo' => 'bar') or ['foo' => 'bar']). Rather than having to make a $class = new stdClass() or casting an array into an object.
• Arrays have various sort() functions.
• Arrays have an easier (subject to opinion) way of referencing dynamic key names, e.g. $array[$key] rather than $array->$key.
• An object in PHP implies (to me) that there will be methods on the object. As a JSON payload will never have methods on the resulting object, it seems like an array is a better fit.

Although the change to Project module is actually fairly minimal, going forward I believe the $payload variable will be an easier and more consistent to work with if it is an array rather than an object. What do you think?

[Gormartsen]

My first reaction was "Why not, it does not really matter".

But then I started to think about it and there is why I think we should keep it as object:

• Payloads and most of GetRequests to GitHub API return readonly data. You should not change or manipulate it.

  It is object by content. For example when you request user info $user = $githubapi->getUser('username');

  you get an object of user information. Like $user->login, $user->name and etc.

• GitHubAPI class use Curl class to do a requests to GitHub API server. Curl class automatically decode JSON to object. To return an array we actually need to do

$response  =json_decode(json_encode($response), TRUE);

Instead of just converting object to array for payloads and answers from GitHub API server, I would create classes:

• Payload family classes - This class provide methods to get information. Like
  • $PayloadPush->getCommits();
  • $PayloadPullRequest->getNumber();
  • etc
• response family classes - will provide a standard interface for each part of API
  • RepositoryClass with methods getRepo() setHook() deleteHook() and etc
  • OrganisationClass with methods to get and manipulate organization data
  • UserClass with methods to get and manipulate user data
  • issuesClass with methods to get and manipulate issue data like $issueClass->addComment()

But I don't really want to do it at this stage of development. This stuff is necessary for really HUGE project where such level of abstraction is required.

[Gormartsen]

Ok, I made $payload an array for now. Updated githubapi is common ...

[Gormartsen]

backdrop-contrib/project#13

[quicksketch]

Great thanks! Per our Gitter discussion, the reason for this ultimately was because we didn't want to cast to arrays for things like $payload->commits, which would have required something like:

foreach ((array) $payload->commits as $commit) {

Using an array makes for easier manipulation. Long-term we may switch to a more structured (object-based) payload, but for now an array structure directly from the GitHub REST service is simple and effective.

Thanks Gor for making this change. I've merged in https://github.com/backdrop-contrib/project/pull/13 as well, fewer changes now required over there because of this switch.