Sent from my iPhone
> On 6 Oct 2024, at 09:38, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote:
>>>> On 3 Oct 2024, at 01:48, Larry Garfield <la...@garfieldtech.com> wrote:
>>>
>>> Since Jim's RFC proposal was criticized for being too vague, I hereby
>>> offer a somewhat more prescriptive policy proposal on using 3rd party code.
>>> (With JIm's blessing.) It's still more heuristics than rules, but I think
>>> that's the right approach generally. It also includes a voting mechanism
>>> to resolve edge cases when they come up.
>>>
>>> I'm sure we'll bikeshed it to death, but please keep an open mind about the
>>> concept in the first place. PHP is more than just php-src, and that's a
>>> good thing. We need to catch up with that reality, while at the same time
>>> maintaining a reasonable neutrality about projects Internals doesn't manage
>>> directly.
>>>
>>> https://wiki.php.net/rfc/third-party-code
>>>
>>> *Puts on trusty flame-retardant suit*
>>>
>>> --
>>> Larry Garfield
>>> la...@garfieldtech.com
>>>
>>
>> Hi Larry,
>>
>> Can you expand a bit more on this item from the exclusion list?
>>
>>> The library is a “full” application or framework.
>> To me that would mean anything that can be executed itself (be it a web
>> app, a command like tool or daemon, etc.
>>
>> But then you specifically say Composer and PHPUnit and Psalm and
>> PHPstan are explicitly allowed... aren't all of them "full"
>> applications, because they can be executed in and of themselves.
>>
>> So, can you perhaps define what you mean by "full application" a little
>> more clearly?
>>
>> Cheers
>>
>> Stephen
>
> A number of people are concerned that if we use any of the "Big Names", it
> would be interpreted as an endorsement of that project. Eg, if we rebuilt
> the main website using Laravel, the Symfony folks would feel slighted. If we
> used Symfony, the Laravel folks would get rather cross. If we used Yii, the
> Slim folks would get upset. If we used Drupal, we'd get constant "well why
> not Wordpress?" questions. Etc.
>
> While I feel that concern is sometimes over-blown, I do believe it is valid.
> Notably, the "big name communities" tend to also be complete, integrated
> solutions, and those also tend to be where there's more active competition.
> Eg, there's only one meaningful Yaml implementation the market, and two UUID
> libraries worth mentioning. But there's literally dozens of "frameworks" or
> "CMSes" to get mad at us.
>
> So banning "full" frameworks is my attempt at steering clear of the
> appearance of that kind of favoritism. Showing favoritism for Composer or
> Xdebug is, well, there's no competition to complain. PHPUnit is technically
> not the only testing framework on the market, but it has north of 90% share
> (and is used internally by some of the few others). But showing favoritism
> between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier.
>
> A full framework also makes maintenance potentially more challenging, as we
> it's a much larger external moving target than a UUID library that we could
> easily fork in a worst case scenario.
>
> So... I don't really have a solid, clear definition of what constitutes a
> "full framework", because in the market, there isn't one. I'm sure someone
> could make a compelling argument that Slim isn't a full framework, for
> instance, although I don't think I'd agree with it.
>
> It is inherently squishy, which is why these are intended as heuristics, not
> strict rules, and when it's unclear we can bring it to a vote via RFC, case
> by case.
>
> I'm open to better ways to define what "full" means here if anyone has
> suggestions.
>
> --Larry Garfield
>
Hi Larry,
Right I understand the motivation, it's just the phrasing that I think needs to
be clarified.
From what you've said (which is kind of what I imagined you probably meant) I
think it just needs to be clarified that the "full application" exclusion is
about *web* applications, and doesn't applying to command line
tooling/utilities.
Cheers
Stephen
