After some consideration and lack of enthusiasm; I'm withdrawing this RFC.
— Rob
On Sun, Jun 30, 2024, at 13:37, Saki Takamachi wrote:
>
> Hi,
>
>> On Sun, Jun 30, 2024, at 13:05, Saki Takamachi wrote:
>>>
>>> Hi,
>>>
> I'm not sure. Does this mean that such "hack" is unavoidable?
>
> And I don't really understand what "pointless hack" means. This would
Hi,
>> On Sun, Jun 30, 2024, at 13:05, Saki Takamachi wrote:
>>
>> Hi,
>>
I'm not sure. Does this mean that such "hack" is unavoidable?
And I don't really understand what "pointless hack" means. This would make
sense if operator overloading was already allowed, but it isn't
On Sun, Jun 30, 2024, at 13:05, Saki Takamachi wrote:
>
> Hi,
>
>>> I'm not sure. Does this mean that such "hack" is unavoidable?
>>>
>>> And I don't really understand what "pointless hack" means. This would make
>>> sense if operator overloading was already allowed, but it isn't.
>>
>> Not
Hi,
>> I'm not sure. Does this mean that such "hack" is unavoidable?
>>
>> And I don't really understand what "pointless hack" means. This would make
>> sense if operator overloading was already allowed, but it isn't.
>
> Not unavoidable, but pointless. For example, I attempted to create a Stri
On Sun, Jun 30, 2024, at 09:31, Saki Takamachi wrote:
> Hi,
>
> >> It seems like the "hack" I mentioned is still possible, am I
> >> misunderstanding something?
> >
> > That’s always going to be a possibility, no matter what we do or how we do
> > it. I think it would be a rather pointless ha
Hi,
>> It seems like the "hack" I mentioned is still possible, am I
>> misunderstanding something?
>
> That’s always going to be a possibility, no matter what we do or how we do
> it. I think it would be a rather pointless hack now that I can run the code.
> For the most part, the engine treat
On Sun, Jun 30, 2024, at 06:59, Rob Landers wrote:
>
>
> On Sun, Jun 30, 2024, at 01:28, Saki Takamachi wrote:
>> Hi,
>>
>> > Hello internals,
>> >
>> > I've updated the RFC to include final-ish examples (barring any further
>> > constructive feedback), a prototype implementation, and an objec
On Sun, Jun 30, 2024, at 01:28, Saki Takamachi wrote:
> Hi,
>
> > Hello internals,
> >
> > I've updated the RFC to include final-ish examples (barring any further
> > constructive feedback), a prototype implementation, and an objections
> > section.
> >
> > Cheers,
> >
> > Rob
>
> It seems
Hi,
> Hello internals,
>
> I've updated the RFC to include final-ish examples (barring any further
> constructive feedback), a prototype implementation, and an objections section.
>
> Cheers,
>
> Rob
It seems like the "hack" I mentioned is still possible, am I misunderstanding
something?
An
Hello internals,
I've updated the RFC to include final-ish examples (barring any further
constructive feedback), a prototype implementation, and an objections section.
Cheers,
Rob
On Friday, 28 June 2024 at 18:46, Rob Landers wrote:
> Hello internals,
>
> I'd like to introduce a new RFC:
> https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP
> extension to support a limited set of operator overriding to developers. It's
> designed to be limited and rel
On Sat, Jun 29, 2024, at 17:37, Ben Ramsey wrote:
> > On Jun 29, 2024, at 10:16, Larry Garfield wrote:
> >
> > For clarity (since I know from experience it's helpful to RFC authors to
> > have a concrete sense of votes in advance): I will be voting No on this
> > RFC. As both Jordan and Saki h
> On Jun 29, 2024, at 10:16, Larry Garfield wrote:
>
> For clarity (since I know from experience it's helpful to RFC authors to have
> a concrete sense of votes in advance): I will be voting No on this RFC. As
> both Jordan and Saki have explained, it's a hideous hack that doesn't look
> like
On Sat, Jun 29, 2024, at 16:19, Saki Takamachi wrote:
> Hi,
>
> >> Here are my thoughts on your code.
> >>
> >> In theory, inheriting from this "improved GMP class" would allow
> >> overloading of computational operators.
> >>
> >> In effect, this acts like a "calcable interface", with the cons
On Sat, Jun 29, 2024, at 7:28 AM, Saki Takamachi wrote:
> Hi,
>
>> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
> 4. The `static` distinction is also fairly meaningless, as in PHP there
> is no situation possible where an operator overload can occur WITHOUT it
> operating on o
I'll add a little more.
> I would like to state my opinion on this matter, making it clear that I am of
> the opinion that "GMP class should be final."
>
> First of all, to meet the requirements that are the basis of this discussion,
> it is not actually necessary to expose the calculation logi
Hi,
>> Here are my thoughts on your code.
>>
>> In theory, inheriting from this "improved GMP class" would allow overloading
>> of computational operators.
>>
>> In effect, this acts like a "calcable interface", with the constructor
>> passing in meaningless values to the parent constructor an
On Sat, Jun 29, 2024, at 14:28, Saki Takamachi wrote:
>
> Hi,
>
>> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
> 4. The `static` distinction is also fairly meaningless, as in PHP there
> is no situation possible where an operator overload can occur WITHOUT it
> operating on
Hi,
> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
>>> 4. The `static` distinction is also fairly meaningless, as in PHP there is
>>> no situation possible where an operator overload can occur WITHOUT it
>>> operating on objects themselves.
>>
>> For this, that is the wrong approach. Th
On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
>>> 4. The `static` distinction is also fairly meaningless, as in PHP there is
>>> no situation possible where an operator overload can occur WITHOUT it
>>> operating on objects themselves.
>>
>> For this, that is the wrong approach. The act
On Sat, Jun 29, 2024, at 11:01, Rob Landers wrote:
> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
>>
>>
>> On Fri, Jun 28, 2024 at 12:55 PM Rob Landers wrote:
>>> __
>>>
>>>
3. The private/protected distinction is fairly meaningless for the
functions that implement overloa
On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote:
>
>
> On Fri, Jun 28, 2024 at 12:55 PM Rob Landers wrote:
>> __
>>
>>
>>> 3. The private/protected distinction is fairly meaningless for the
>>> functions that implement overloads, because the privacy of the function is
>>> ignored complet
On Fri, Jun 28, 2024 at 12:55 PM Rob Landers wrote:
>
>
> 3. The private/protected distinction is fairly meaningless for the
> functions that implement overloads, because the privacy of the function is
> ignored completely when it is executed to evaluate an operator.
>
>
> Hmm. I like the idea of
On Fri, Jun 28, 2024, at 20:39, Jordan LeDoux wrote:
>
>
> On Fri, Jun 28, 2024 at 10:47 AM Rob Landers wrote:
>> __
>> Hello internals,
>>
>> I'd like to introduce a new RFC:
>> https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP
>> extension to support a limited set of
On Fri, Jun 28, 2024 at 10:47 AM Rob Landers wrote:
> Hello internals,
>
> I'd like to introduce a new RFC:
> https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP
> extension to support a limited set of operator overriding to developers.
> It's designed to be limited and relativ
26 matches
Mail list logo
