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

BindingType issues #194

Open
Nyholm opened this issue Jul 29, 2016 · 3 comments
Open

BindingType issues #194

Nyholm opened this issue Jul 29, 2016 · 3 comments
Assignees
Milestone

Comments

@Nyholm
Copy link
Member

Nyholm commented Jul 29, 2016

The BindingType class changed it constructor in puli/discovery#33. We have about 500 places in our code where we use that constructor. The all have to be changed.

The new BindingType requires you to have a $bindingClass is that really necessary at construct time? Most of the calls to that constructor does not have that info.

@webmozart
Copy link
Member

The BindingType constructor changed in this way in order to enforce a type to be used with one single binding class. That is, if you declare a binding type My\\Interface for classes, then only classes should be bound to this type, not resources.

There is a pending PR to adapt the Manager component here: puli/manager#56

The final goal is to declare binding types and bindings like this:

{
    "provide": {
        "Some\\Plugin": "My\\PluginInterface",
        "Some\\Other\\Plugin": {
            "binding-type": "My\\PluginInterface",
            "parameters": { "alias": "phpdoc" }
        }
    },
    "binding-types": {
        "My\\PluginInterface": {
            "accept": "class",
            "parameters": {}
        },
        "my/translations": "resource"
    }
}

Would you like to work on this?

@Nyholm
Copy link
Member Author

Nyholm commented Aug 14, 2016

I've made some PR for this issue now. Please review

@webmozart
Copy link
Member

related to #201

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

2 participants