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 <[email protected]> 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 protected, because it gives a structure to it that is apparent
>>> and usable right from the IDE. You just “fill in the blanks” or stick with the default behavior.
>>>
>>
>> I do not understand how the visibility has any impact on the usability you are seeking to
>> provide.
>
> I guess it depends on what you mean by usability. From a technical standpoint, it has zero
> usability, but from a dev-ex standpoint, it has a huge amount of usability.
>
> If we add these as protected methods to the base class, I merely need to write "protected
> static function<tab>" in my IDE and I will see all the methods I can write. It also lays
> bare "how it works" for a PHP developer without any magic, making it easier to document.
>
>>
>>>> 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 actual behavior is on the type, not the
>>> instance. The object instances may not even know their value, they merely represent the value.
>>
>> A GMP object instance that does not know its value? What are you even talking about? Can
>> you show me some code explaining what you mean? I had literally months of this argument for the
>> operator overloads RFC, and studied the overload implementations in six other languages as part of
>> writing that RFC, I feel like I understand this topic fairly well. But I do not understand what you
>> are saying here.
>
> Heh, yeah, it's kinda weird. Let me explain. The GMP class hides its value in a
> "private" member (because the value isn't actually a number, but a GMP resource), so
> unless the programmer also sets the value to something they have access to, they won't know the
> value (but they can always cast $this to a number or operate on it directly). The only way they
> could get the value is to cast $this to float, which may lose some precision. The idea here is to
> "write the rules" where the value doesn't matter, or if it does, embed that as part
> of the rules.
>
> For example, imagine we want to create a Field class, that takes a range for the field and
> keeps the value in the field. It might look something like this:
sigh: not enough coffee again and I saw the blunder as soon as I sent it.. Here's the more
correct implementation.
class IntField {
public function __construct(private int $max, int $value) {
parent::construct($value, 10);
}
protected static function add($left, $right): self {
// todo: guard that left can be added to right -- ie, both are integers
$result = parent::add($left, $right);
if ($result >= $left->max) return new IntField($left->max, $result % $left->max);
return new IntField($left->max, $result);
}
// todo: remaining implementation
}
> I actually had a bit of a long-thought about it, and I think this is simpler (both to implement
> and to use) than the traditional approach, and more powerful. With the more traditional approach,
> how do define communitive rules? You are bound by traditional mathematics, more-or-less. From
> working in cryptography, a long time ago now, I can say that there are non-communitive rings where
> having access to both "left" and "right" can allow you to handle this quite
> well.
>
>>
>>>
>>>> 6. The comparable function you propose doesn't actually have an
>>>> operator it corresponds to. There is no operator in PHP for "is the left value comparable with
>>>> the right value". There are operators for comparisons themselves, which I assume you meant, but
>>>> a bool is insufficient as a return type for that.
>>>
>>> In the engine, there’s just a compare function for internal overrides. So we just
>>> check that everyone agrees that the two objects are comparable and then pass it on to “business as
>>> usual.”
>>
>> I'm aware of how the compare handler for class entries and zend_compare interact.
>> What I am saying is that your design is insufficient for <=>. You cannot return
>> false from this method to mean uncomparable, and true to mean comparable.
>> The zend_compare function can validly return 0 or -1, with the -1 being used for both less than OR
>> greater than because the operands are reordered to always be a less than comparison. Then 1, which
>> normally is used for greater than, is used to mean uncomparable.
>
> Ah, I mean that it calls this as a guard, before ever doing a comparison, not that this output
> will be used for comparison itself. This is deliberate, to keep it simple. If I get feedback that
> comparison should be implemented vs. a guard for comparison, I'd be happy to add it.
>
>> As you are proposing this without any genuine expectation you can pass it, this will be the
>> last energy I will invest into helping.
>
> I didn't mean it how I think you are taking it. To expand a bit on what I meant,
> "we" (as in people who want this feature, like myself) can only create RFCs for it. Maybe
> one day, the voters will change their mind, "we" will find an implementation they agree
> with, or they'll forget to vote "no" while enough people vote "yes." So,
> yes, I genuinely want this feature and I want to propose a feature that works and is the best I can
> come up with; at the same time, I don't expect it to pass, but I do hope that negative feedback
> will drive the feature to a compromise or solution that works. The only way to get there is by
> failing.
>
> — Rob
— Rob