Closed ErikGrimes closed 10 years ago
I thought I already replied to this ...
In principle I agree 100%.
But in polymer-elements only the examples depend on polymer-ui-elements. We could move the examples out of the package but I consider it documentation and would not want to split implementation and docs. Should there arise a dependency from a custom element in polymer-elements to polymer-ui-elements I would consider this an error.
polymer-ui-elements depend heavily on polymer-elements but that is fine.
Another solution would be to pack all elements in one package. But as long that custom elements in polymer-elements don't rely on polymer-ui-elements I find this a good abstraction which I would not remove.
What do you think?
I like having the examples with the package. Let's leave things as they are.
On Thu, Nov 7, 2013 at 5:47 AM, Günter Zöchbauer notifications@github.comwrote:
I thought I already replied to this ...
In principle I agree 100%.
But in polymer-elements only the examples depend on polymer-ui-elements. We could move the examples out of the package but I consider it documentation and would not want to split implementation and docs. Should there arise a dependency from a custom element in polymer-elements to polymer-ui-elements I would consider this an error.
polymer-ui-elements depend heavily on polymer-elements but that is fine.
Another solution would be to pack all elements in one package. But as long that custom elements in polymer-elements don't rely on polymer-ui-elements I find this a good abstraction which I would not remove.
What do you think?
— Reply to this email directly or view it on GitHubhttps://github.com/ErikGrimes/polymer_elements/issues/64#issuecomment-27956406 .
I'm not sure why the dependency is there, but circular dependencies are a pretty bad code smell.