On Tue, Mar 3, 2020, at 4:58 PM, Dan Ackroyd wrote:
> Paul M. Jones wrote:
>
> > Are there any members here who currently expect to vote "no",
>
> The only reason for doing this as C code appears to be make it have
> read-only properties. This is a hack that would confuse a lot of
> developers,
Paul M. Jones wrote:
> Are there any members here who currently expect to vote "no",
The only reason for doing this as C code appears to be make it have
read-only properties. This is a hack that would confuse a lot of
developers, and instantly be added to most lists of "how PHP is bad".
I reall
On 26.02.2020 at 11:17, Sebastian Hopfe wrote:
> php-qa
Would you please elaborate on which parts of QA you would want to work?
Do you have already contributed? A quick introduction of yourself would
be certainly appreciated as well.
Thanks,
Christoph
--
PHP Internals - PHP Runtime Developmen
Hi all,
we still have 2 bundled extensions for working with strings in different
encodings: ext/mbstring and ext/iconv. While working on bug #79200[1],
I've noticed that the implementation of many of the iconv_*() functions
is rather suboptimal. This is mostly because iconv() is meant just for
On Tue, Mar 3, 2020 at 10:40 PM Levi Morrison
wrote:
> On Tue, Mar 3, 2020 at 8:01 AM Nikita Popov wrote:
> >
> > On Fri, Feb 7, 2020 at 11:32 AM Nikita Popov
> wrote:
> >
> > > Hi internals,
> > >
> > > I've sent a mail about this before, but as this turned into a bit of a
> > > larger change
On Tue, Mar 3, 2020 at 8:01 AM Nikita Popov wrote:
>
> On Fri, Feb 7, 2020 at 11:32 AM Nikita Popov wrote:
>
> > Hi internals,
> >
> > I've sent a mail about this before, but as this turned into a bit of a
> > larger change (also allowing "abstract private" methods in traits) and
> > there's some
> I feel like the results of this poll aren't going to be particularly
> meaningful, because it gets too caught up in the details and loses track of
> the big picture.
I'd definitely agree. If I was writing the RFC for calls in constant
expressions again,
I'd focus more on adding concrete example
On Tue, Mar 3, 2020 at 9:11 AM Nikita Popov wrote:
> Currently, when writing something like
>
> use T1, T2 {
> func as renamedFunc;
> }
>
> where both T1::func() and T2::func() exist, we silently allow this and just
> assume that it is referring to T1::func(). See https://3v4l.org
On Tue, Feb 25, 2020 at 4:33 PM Nikita Popov wrote:
> Hi internals,
>
> I've put up https://github.com/php/php-src/pull/5209 to deprecate the
> following reflection methods:
>
> * ReflectionParameter::isArray()
> * ReflectionParameter::isCallable()
> * ReflectionParameter::getClass()
>
> These
On Mon, Feb 17, 2020 at 3:09 AM tyson andre
wrote:
> Hi internals,
>
> I've created a straw poll at
> https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
> interest in allowing calls in different types of constant expressions.
> If there aren't any problems with the poll stru
On Tue, 3 Mar 2020 at 14:45, Terje Slettebø <
terje.slett...@sandefjordbredband.net> wrote:
>
> I agree that this makes sense. However, as someone else pointed out, one
> problem with interfaces is that they constrain the types that may be used.
>
An interface doesn't have to define types, and i
On Tue, Mar 3, 2020 at 4:06 PM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le mardi 3 mars 2020, 15:11:27 CET Nikita Popov a écrit :
> > As the error message indicates, the ambiguity is resolved by writing
> >
> > use T1, T2 {
> > T1::func as renamedFunc;
> > //
Le mardi 3 mars 2020, 15:11:27 CET Nikita Popov a écrit :
> As the error message indicates, the ambiguity is resolved by writing
>
> use T1, T2 {
> T1::func as renamedFunc;
> // or
> T2::func as renamedFunc;
> }
>
> depending on which of those you actually meant.
On Fri, Feb 7, 2020 at 11:32 AM Nikita Popov wrote:
> Hi internals,
>
> I've sent a mail about this before, but as this turned into a bit of a
> larger change (also allowing "abstract private" methods in traits) and
> there's some backwards compatibility impact, I've created a proper RFC for
> th
Hi Rowan.
I agree that this makes sense. However, as someone else pointed out, one
problem with interfaces is that they constrain the types that may be used.
We have our own Money, Percentage, PricePerMm, etc. types that we'd like
to define operators for, how can you define an interface in PH
Hi internals,
Currently, when writing something like
use T1, T2 {
func as renamedFunc;
}
where both T1::func() and T2::func() exist, we silently allow this and just
assume that it is referring to T1::func(). See https://3v4l.org/6h3PM for a
more complete example.
I would like to
Am 03.03.20 um 14:29 schrieb Nicolas Grekas:
> Le mar. 3 mars 2020 à 11:04, Rowan Tommins a
> écrit :
>
>> On Tue, 3 Mar 2020 at 08:46, Andreas Heigl wrote:
>>
>>>
>>> While it is mainly aimed at being a mere convenience-function that could
>>> also be easily implemented in userland it misses
Le mar. 3 mars 2020 à 11:04, Rowan Tommins a
écrit :
> On Tue, 3 Mar 2020 at 08:46, Andreas Heigl wrote:
>
> >
> > While it is mainly aimed at being a mere convenience-function that could
> > also be easily implemented in userland it misses one main thing IMO when
> > handling unicode-strings: N
>
> Ironically, this broke Symfony ;)
>
> > Fatal error: Access level to class@anonymous::__toString() must be
> public (as in class Stringable) in
> /home/vsts/work/1/s/symfony/src/Symfony/Component/String/Tests/LazyStringTest.php(110)
> : eval()'d code on line 1
>
>
>
Indeed!
Fixed in https://git
On Tue, 3 Mar 2020 at 08:46, Andreas Heigl wrote:
>
> While it is mainly aimed at being a mere convenience-function that could
> also be easily implemented in userland it misses one main thing IMO when
> handling unicode-strings: Normalization.
>
>
While I would love to see more functionality fo
On Thu, Feb 27, 2020 at 9:49 AM Nicolas Grekas
wrote:
> Hello everyone,
>
> I happy to open the vote for the Stringable RFC:
> > https://wiki.php.net/rfc/stringable#vote
> >
> > The vote will stay open until 2020-02-26.
> >
>
> The proposal has been accepted with 29 "Yes" votes and 9 "No.
>
> The
Hi Terje,
I think both of your examples are compatible with the idea of grouped
operators, as long as we don't constrain a type to implement all operators
with the same right-hand side.
On Mon, 2 Mar 2020 at 17:23, Terje Slettebø <
terje.slett...@sandefjordbredband.net> wrote:
>
> Adding and su
Hey all.
Just a short note why I voted against the current implementation of the
str_contains functionality.
While it is mainly aimed at being a mere convenience-function that could
also be easily implemented in userland it misses one main thing IMO when
handling unicode-strings: Normalization.
23 matches
Mail list logo
