On Thu, Dec 16, 2021 at 4:21 AM Andreas Hennings
wrote:
>
> Having one side of the operator "own" the implementation feels wrong,
> and could lead to problems with inheritance down the line.
>
> From C++ I remember that at the time, there was a philosophy of
> defining and implementing these kind
On Thu, Dec 16, 2021, at 1:24 PM, Andreas Hennings wrote:
> I see the distinction in overloading based on the object type on the
> left, vs overloading based on parameter types.
>
> For a method call $a->f($b), the implementation of ->f() is chosen
> based on the type of $a, but not $b.
> For an o
We cannot break that without giving sufficient time to the respective
maintainers to update these extensions to use the new CMake build
system. If we can maintain both build chains for some years
Yes, gradually phasing the current build system out is the most
pragmatic choice, although it will
On 16.12.2021 at 22:31, Horváth V. wrote:
>> I think the answer should be that _eventually_ they should have to
>> migrate, but in the interim we must maintain two build systems.
>
> You are right on the first point, but it is not a requirement for
> php-src to be managed by anything other than CM
I think the answer should be that _eventually_ they should have to
migrate, but in the interim we must maintain two build systems.
You are right on the first point, but it is not a requirement for
php-src to be managed by anything other than CMake to maintain phpize
functionality for existing 3r
On Thu, Dec 16, 2021 at 1:13 PM Horváth V. wrote:
>
> > My main question would be how this will affect 3rd party extensions,
> > which are currently using autoconf. Will they need to migrate to
> > cmake, or will we have to effectively maintain both build systems?
>
> Unless 3rd party extensions v
My main question would be how this will affect 3rd party extensions,
which are currently using autoconf. Will they need to migrate to
cmake, or will we have to effectively maintain both build systems?
Unless 3rd party extensions vendor php-src and/or do something extra
besides what they are ins
On Thu, 16 Dec 2021 at 19:20, Dan Ackroyd wrote:
>
> On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
>
> > Methods and functions have searchable and clickable names. Operators don't.
> > The "searchable" applies to grep searches in code, but also google
>
> That's one of the reasons why I p
On Thu, Dec 16, 2021 at 6:54 PM Horváth V.
wrote:
> Hello internals,
>
> I'm writing to you to find out what the reception here is regarding the
> idea of moving the PHP project to build using CMake.
>
> I have looked around and I found 2 attempts of doing just that in the
> past (in 2008 via GSo
Hi Horváth,
just wanted to give my +1 on this one. For our use-case (PHP Embed, ZTS,
Static Build) this would greatly simplify our build-system which is already
using CMake in a lot of parts. Unfortunately I am not a CMake expert, but
could offer help in testing and feedback.
Regards,
Michael
Am
On Thu, 16 Dec 2021 at 08:24, Pierre wrote:
>
>
> If the names are a problem, why not registering those using an attribute
> ?
If there is a strong reason to use attributes, then the argument
should start from there.
Starting from "well we could just use an attribute" and then putting
the pressu
On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
> Methods and functions have searchable and clickable names. Operators don't.
> The "searchable" applies to grep searches in code, but also google
That's one of the reasons why I prefer a magic methods based approach.
function __plus(...){}
Hello internals,
I'm writing to you to find out what the reception here is regarding the
idea of moving the PHP project to build using CMake.
I have looked around and I found 2 attempts of doing just that in the
past (in 2008 via GSoC and something else maybe in 2014 that I couldn't
find the exa
Hello internals,
some concerns I have about operator overloading.
(I have seen and played with operator overloading long time ago in
C++, this is my background for these points.)
1. Searchable names.
Methods and functions have searchable and clickable names. Operators don't.
The "searchable"
Le 16/12/2021 à 05:01, Jordan LeDoux a écrit :
This is not a use case I highlighted because it's one that would be
difficult to support with this RFC. But as you say, it could be a good
future expansion. In particular, putting a query builder object into core
with some more advanced overloads bui
15 matches
Mail list logo
