Ported library to libgit 0.19 #53
Conversation
|
I think they let it die. Sad because I could have used it. |
|
I'm sorry about missing this PR. I was very busy on that days. we consider throw away OOP interface before propose PECL as It tough to follow latest changes. |
|
Yeah, switching to functions would probably make things a lot easier, and users could just fallback to the official API documentation for what to expect from each function call. I don't mind having a go at it when I have some time later. |
|
I would prefer the option for OOP interfaces, because I would like to be able to extend them, if I need to. Also passing Objects is much easier than having to use functions. Feel free to offer functions but like PHP does with a lot of extensions offer the interfaces as well. |
|
Have you read http://libgit2.github.com/libgit2/#HEAD ? If we provide right OOP interface continuously, we will stop development as considering right interfaces (especially, Keeping compatibilities) are very tough task in this large scale library. Almost people can't do full-time work for OSS library. So switching to functions is better choice. Then we could easy to follow latest API, maintain it and accept PRs. Unfortunately, keeping OOP classes are very low priority. Then, why current php-git provides classes? Because libgit2 was small library at that time. |
|
Well, with that in mind I guess I can understand it. Too bad we didn't have more people who know extension coding who were interesting in helping out. I myself am looking into it now to see if I can be of some help to it. |
|
What could be done is that while the extension switches to procedural functions, the OOP wrapper can be written as a separate PHP library that can then be maintained by the users without having them deal with the C internals of PHP. |
Just some quick changes and all tests pass without issues.
If necessary I could probably publish and maintain the package on PECL.