I might be missing something here, but these two are not in the same problem field, are they?
Symfony has a PropertyInfo component for years, which uses PHPstan and phpDocumentor's type packages (the one you're linking here!) to resolve property types. This component used to have a single Type DTO class representing all type information.
Q
A
Branch?
7.1
Bug fix?
no
New feature?
yes
Deprecations?
no
Tickets
License
MIT
Doc PR
TODO
Introducing the brand new TypeInfo component
This work has been done with @Korbeil
...
@jaapio I just always get very triggered by people mentioning NIH in Symfony.
For me, it feels like we get accused of having a secret plan to get all PHP packages to start with "symfony/" in some years.
From working in this group, I know this is not the case and we're all just eager to write code and publish features (+ save ourselves maintenance time). Most of our discussions happen in the open on GitHub and we have no secret bad intentions to any individual on this world.
@jaapio I realize this sometimes isn't the feeling that we get across.
Async communication, and textual async communication in particular, looses a lot of emotion and can result in bad feelings for people reading them.
Please reach out to us if this is the case, like you did. We'll learn from it, be better at communication in the future, and create new contacts with the PHP community for the better of everyone.
@wouterj I know that the symfony team has the best of intentions and I had great chats with a few of them also about that topic. Still IMO what comes across often is NIH approach. Especially with people not that deep into the community - which is kinda most users...
And while I can and do understand the reasonings behind the approach I still believe that there might be other ways.
And if it is only to very early get in contact with maintainers of external packages...
@wouterj @jaapio I know what a number of the concerns are that prompt things like this. That said, having been an author of several components where this happened, I can also say that it's hugely dispiriting when your work is essentially forked and modified only slightly, just so it can comply with the Symfony release lifecycle or its preferred API. You end up losing users and contributors, and any fixes or improvements on the symfony version never make it back to the original. 😐
@mwop in this can it wasn't an adoptation but just a new build project. However when I read the code it's very likely that the authors had a look at my project. Class names are equal, and also the structure of the code looks much like the original project.
I would have been open to help them out, which I did before. If I just got a question. It's not that phpDocumentor is a new project. And with more that 7M downloads a month it's not that you can not trust it.
Neverless, I had a very nice chat with the symfony team, so maybe we can change this way of handling. We are all humans making decisions, and not everybody has to agree.
I agree, let's become more converging as a PHP community and ping authors of relevant packages in the community reviews (if we know them ofc).
That said, I think this also applies to how we deal with it afterwards. Messages like your first post often result in a more diverging community. Let's try to understand, from both sides, and not shoot one-liners. People reading the message don't know about those "great chats" and will only remember Symfony being the bad guy.
@wouterj @jaapio crazy idea, but why does Symfony not publish about plans for new components, and invite the wider community to collaborate? Instead right now, the new components are announced when they are done and it is a surprise to "competing" component maintainers. This results in comments about Symfony's NIH syndrome that, while perhaps not the best way to communicate this, I can honestly understand. That is by now my default response as well when I see something like this.
@Skoop Or perhaps, instead of maintain a new version of an already established project, create a slim wrapper around the existing lib that can make sure that all the specific needs for Symfony are met.
Less maintenance-burden and perhaps even time to contribute to the existing lib
@Skoop the reality is that there is very little plan. If we say we don't have a roadmap, we mean it :)
For those announced at conferences, the component is just as much as a surprise for you as it is for the core team (I'm also totally not sure if that's a good thing!)
For all other components, the first time we hear about it is when the PR with a draft idea is opened. This applies to components created by core team members, and by ones created by community members.
@wouterj @jaapio so perhaps we should implement a new flow. One where collaboration and communication is more central. To promote reuse and interoperability for libraries and frameworks.
Perhaps we should create a group, let's call is the Library Interoperability Group, LIG for short, where these things can be discussed.
Philip Weinke
in reply to Senior Rabbit-Hole Explorer • • •Senior Rabbit-Hole Explorer
in reply to Philip Weinke • • •symfony/src/Symfony/Component/TypeInfo at 7.1 · symfony/symfony
GitHubWouter de Jong
in reply to Senior Rabbit-Hole Explorer • • •I might be missing something here, but these two are not in the same problem field, are they?
Symfony has a PropertyInfo component for years, which uses PHPstan and phpDocumentor's type packages (the one you're linking here!) to resolve property types. This component used to have a single Type DTO class representing all type information.
Last year, some community members proposed the TypeInfo component as a better replacement for this Type class (https://github.com/symfony/symfony/pull/52510).
[TypeInfo] Introduce component by mtarld · Pull Request #52510 · symfony/symfony
GitHubJaapio
in reply to Wouter de Jong • • •Wouter de Jong
in reply to Jaapio • • •Let's keep talking and see where our needs overlap and we can work together, just like on the rst parser.
Wouter de Jong
in reply to Wouter de Jong • • •@jaapio I just always get very triggered by people mentioning NIH in Symfony.
For me, it feels like we get accused of having a secret plan to get all PHP packages to start with "symfony/" in some years.
From working in this group, I know this is not the case and we're all just eager to write code and publish features (+ save ourselves maintenance time). Most of our discussions happen in the open on GitHub and we have no secret bad intentions to any individual on this world.
Wouter de Jong
in reply to Wouter de Jong • • •@jaapio I realize this sometimes isn't the feeling that we get across.
Async communication, and textual async communication in particular, looses a lot of emotion and can result in bad feelings for people reading them.
Please reach out to us if this is the case, like you did. We'll learn from it, be better at communication in the future, and create new contacts with the PHP community for the better of everyone.
Senior Rabbit-Hole Explorer
in reply to Wouter de Jong • • •@wouterj I know that the symfony team has the best of intentions and I had great chats with a few of them also about that topic. Still IMO what comes across often is NIH approach. Especially with people not that deep into the community - which is kinda most users...
And while I can and do understand the reasonings behind the approach I still believe that there might be other ways.
And if it is only to very early get in contact with maintainers of external packages...
/cc @jaapio
Matthew Weier O'Phinney
in reply to Senior Rabbit-Hole Explorer • • •Jaapio
in reply to Matthew Weier O'Phinney • • •@mwop in this can it wasn't an adoptation but just a new build project. However when I read the code it's very likely that the authors had a look at my project. Class names are equal, and also the structure of the code looks much like the original project.
I would have been open to help them out, which I did before. If I just got a question. It's not that phpDocumentor is a new project. And with more that 7M downloads a month it's not that you can not trust it.
cc @heiglandreas @wouterj
Jaapio
in reply to Jaapio • • •Neverless, I had a very nice chat with the symfony team, so maybe we can change this way of handling. We are all humans making decisions, and not everybody has to agree.
@mwop @heiglandreas @wouterj
Wouter de Jong
in reply to Senior Rabbit-Hole Explorer • • •I agree, let's become more converging as a PHP community and ping authors of relevant packages in the community reviews (if we know them ofc).
That said, I think this also applies to how we deal with it afterwards. Messages like your first post often result in a more diverging community. Let's try to understand, from both sides, and not shoot one-liners. People reading the message don't know about those "great chats" and will only remember Symfony being the bad guy.
/cc @jaapio
Daniel Siepmann likes this.
Skoop (Stefan Koopmanschap)
in reply to Wouter de Jong • • •Daniel Siepmann likes this.
Senior Rabbit-Hole Explorer
in reply to Skoop (Stefan Koopmanschap) • • •@Skoop Or perhaps, instead of maintain a new version of an already established project, create a slim wrapper around the existing lib that can make sure that all the specific needs for Symfony are met.
Less maintenance-burden and perhaps even time to contribute to the existing lib
/cc @wouterj @jaapio
Wouter de Jong
in reply to Skoop (Stefan Koopmanschap) • • •@Skoop the reality is that there is very little plan. If we say we don't have a roadmap, we mean it :)
For those announced at conferences, the component is just as much as a surprise for you as it is for the core team (I'm also totally not sure if that's a good thing!)
For all other components, the first time we hear about it is when the PR with a draft idea is opened. This applies to components created by core team members, and by ones created by community members.
cc @heiglandreas @jaapio
Skoop (Stefan Koopmanschap)
in reply to Wouter de Jong • • •@wouterj @jaapio so perhaps we should implement a new flow. One where collaboration and communication is more central. To promote reuse and interoperability for libraries and frameworks.
Perhaps we should create a group, let's call is the Library Interoperability Group, LIG for short, where these things can be discussed.
Daniel Siepmann likes this.
Daniel Siepmann reshared this.