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

Root Namespace #128

Closed
kelunik opened this issue Dec 31, 2016 · 7 comments
Closed

Root Namespace #128

kelunik opened this issue Dec 31, 2016 · 7 comments

Comments

@kelunik
Copy link
Member

kelunik commented Dec 31, 2016

http://www.php-fig.org/psr/psr-4/ says the root namespace is the "vendor namespace", we aren't the "interop" vendor, we're the "async" vendor I'd say, but I don't feel strongly about it.

@bwoebi
Copy link
Member

bwoebi commented Dec 31, 2016

I don't care, that's just deciding on whether the paint of the shed needs to be a bit lighter or not...

@joshdifabio
Copy link
Contributor

I really don't think the current two-level namespace makes a lot of sense. I think async-interop should use a single-level namespace to group its standards, and I think it'd be fine if that was Async or AsyncInterop, although the latter would better reflect the name of the organisation.

@kelunik
Copy link
Member Author

kelunik commented Jan 2, 2017

At least https://github.com/jderusse/async uses Async currently.

@kelunik
Copy link
Member Author

kelunik commented Jan 2, 2017

https://bitbucket.org/mkjpryor/async/wiki/Home is another package using Async, found via http://packanalyst.com/.

@joshdifabio
Copy link
Contributor

If we plan to use async-interop as the Composer vendor name then I think it's least surprising to use AsyncInterop as the namespace root.

@WyriHaximus
Copy link
Member

If we plan to use async-interop as the Composer vendor name then I think it's least surprising to use AsyncInterop as the namespace root.

I feel strongly about this strategy, this is the least confusing for users and both vendor namespace, composer namespace, and the Github vendor/org match 👍 .

@trowski
Copy link
Contributor

trowski commented Jan 2, 2017

The only reason I can see to continue with Interop\Async is that container-interop uses Interop\Container. Aside from that, AsyncInterop would be the obvious choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants