Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dependency injection for all objects relying on ObjectSpec #82

Merged
merged 8 commits into from
Oct 29, 2019

Conversation

johnny-bit
Copy link
Collaborator

  • Changed ObjectSpec to be non-static class
  • Removed NASK's ObjectSpec methods to better facilitate new ObjectSpec
  • Modified examples to use new ObjectSpec way of doing things
  • Removed unnecessary php-version dependent tests due to non-static ObjectSpec
  • Added HTTPClient connection example
  • Moved COZA extension example to Extension subdir in examples
  • Added documentation in README.md
  • Added recent changes to CHANGELOG.md

…nd frames and client)

* Changed ObjectSpec to be non-static class
* Removed NASK's ObjectSpec methods to better facilitate new ObjectSpec
* Modified examples to use new ObjectSpec way of doing things
* Removed unnecessary php-version dependent tests due to non-static ObjectSpec
* Added HTTPClient connection example
* Moved COZA extension example to Extension subdir in examples
* Added documentation in README.md
* Added recent changes to CHANGELOG.md
@lifeofguenter
Copy link
Member

Amazing work! So the reason get + sendFrame were public, is to allow people to do low-level stuff as there is no good/existing interface to do so currently?

As long as it will still be possible? Obviously cleaner to not have them public, but only if we either support all calls, or have an easy way to inject a custom handler? Not sure?

@johnny-bit
Copy link
Collaborator Author

I wondered about that... Usually one should implement get/sendFrame as a low-level stuff and let request to handle that. The only thing that would technically fail with this approach is long-running stuff where response frame is disassociated with request frame (eg very theoretical EPP-over-SMTP 😝)

What usecases do you see for them being public? Obviously haing them public because no other class publishes them might also be good idea, so I can add that back, no problem :)

@johnny-bit
Copy link
Collaborator Author

Amazing work! So the reason get + sendFrame were public, is to allow people to do low-level stuff as there is no good/existing interface to do so currently?

As long as it will still be possible? Obviously cleaner to not have them public, but only if we either support all calls, or have an easy way to inject a custom handler? Not sure?

made them public again :) and done some refactoring, more testing etc :) Should be ready for mainlining.

@johnny-bit johnny-bit merged commit cabf1c8 into AfriCC:master Oct 29, 2019
@johnny-bit johnny-bit deleted the dependencyinjection branch October 29, 2019 11:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants