Util packages have, I think, been using Fig\ as the top level namespace
segment, not Psr\. At least they're supposed to be... :-)
I am not too bothered if we use the *-util package or start a *-tests package
for this sort of case. But either way, they're not part of the spec and so
should nev
>
>
>>> I totally disagree that there is no need for test packages.
>
Question here is which unit test framework ( may be phpunit ) ? What about
others. Or all in one util package.
> The specifications for the interfaces are generally quite strict, but,
> particularly with versions that do not u
On Tue, Dec 11, 2018 at 12:14 PM Hari K T wrote:
> Hi all,
>
>
>> The package consists of interfaces - so there's nothing really to test,
>> and there's no CI or anything like that set up. (and it wouldn't work if
>> there were, because there's no dependency on PHPUnit although it's
>> extending
Hi all,
> The package consists of interfaces - so there's nothing really to test,
> and there's no CI or anything like that set up. (and it wouldn't work if
> there were, because there's no dependency on PHPUnit although it's
> extending that class.)
>
> This test is for implementations - so thes
> I'm strongly in favor of tests being in the same package as the thing
being testing
Me too - but that's not what this is.
The package consists of interfaces - so there's nothing really to test, and
there's no CI or anything like that set up. (and it wouldn't work if there
were, because there's
As a user, I have no problem with a provided base test class using PHPUnit.
Using PHP's run-tests.php would be a step backwards in my opinion.
However, I do agree that putting this into the package itself was a
mistake, as was the version bump. It should be a -util package, as others
have mentione
On Friday, December 7, 2018 at 10:19:46 AM UTC-6, Rasmus Schultz wrote:
>
> How is this in any way acceptable?
>
I'm strongly in favor of tests being in the same package as the thing being
testing, and CI runs against that being part of the commit process, so in
THAT one way I'd call it "accepta
Yes, out of scope, at least here at the beginning. Once we get a baseline
draft covering the minimal "already in use old stuff" covered, I'm
expecting us to open up topics on "new stuff" to add, generics included.
Not that I'm convinced we'll get that one nailed down to enough agreement
that we ca
At first glance, I think I'm good with moving this out to a log-util
package, with perhaps a bump to v1.2. Adjusting testcases has never really
urged me into being concerned about versioning, at least when working in my
packages. The BC extent of anyone actually depending on these for their
own t
As I've noted on the PR thread:
Introducing the test facilities in the first place was a "bug", and fixing
it will break tests only.
Versioning that fix as a major is wrong, since there are no breaking
changes to the library itself.
If you're very concerned about breaking somebody's tests, you c
Sorry for adding this with so much little notice. I added that since the
other one was already present, and that wouldn't change the number of
implicit dependency on that package.
Obviously not using that class will not trigger any issue, but removing
that now would be a BC, so I'm against doin
This is the issue traking the implementation on
PHPStan: https://github.com/phpstan/phpstan/issues/652
Il giorno sabato 8 dicembre 2018 21:44:14 UTC+1, Chuck Burgess ha scritto:
>
> I'm thinking this use case will probably need to rely on some kind of
> collection/generics syntax. Do we know if
12 matches
Mail list logo
