Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125519 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id E0B121A00BD for ; Thu, 12 Sep 2024 05:21:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726118582; bh=0S/DuB5TMui2J/GNX2YW7suAPXaITlWuXwFOdAavXQ8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=TonY1HlhQdLqt3FB9WYECLojipPRB/wttRdpAZUqoMz4ZrlY6YyEEduj7LRGjmXEw 0Rc3Ou1w+w6qrVUMYsDPX5BAxYGmX3TF1LuM2itbaEgt9rTlWMEq5p0IQk4zPchAkD QWk+ilNdTLeH8zPEKBKB03kYiJhCyOy2HSOFPxk9wZxcThdCXY+H5WRTbe+5UeBEEg YG2PAZTsZDpMqA8x1Z/igA5a6U4aqDFcxfd01AHZZ8c2jB9Eg/Q4cExQZ8AXpm38td ka5QjvX/HdYo34G0knLfackCIkcJ+J01ZcUYwhR8qGRap6iMGpu7hPtsZabRy3azm+ Xjr9m+lp24JQw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 500EE180042 for ; Thu, 12 Sep 2024 05:23:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 12 Sep 2024 05:23:00 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-68518bc1407so5346617b3.2 for ; Wed, 11 Sep 2024 22:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1726118458; x=1726723258; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=78cgp61viNCbwWsOS5mPogRMJR9sAFu8OFHqjWHCdAI=; b=IRosL8qGhXkNKmeByo931CGiB/kR+Q57HoSWgYT5o2Nvx2uv3J6IE/k3taMmdC2/RZ +ZgBS3/vPIUUBcO7yEOJ6cHhZ6XXdaSrLn4A0nPJWy7/7FWort2/OMq3ht0WmAingfb4 lGWK02Q2gqI35t7OGOotgG685dz4RF58ShkcdX0DPGog3AJ6k9D4/p4zM0hV/BcsmrPE 8IjcVSOCBAFBVgTULAyOR/zI3LAYLAgdFAu1K7sRMNqbcS2jyDXDDOYhxoUVFRv9o+rW kyxGd0AsiBEMDkU10kRqaJNKJ9n9OtRc1JiDyRCtf7hUrkbyBoef1BoxrUGRddU8Q7vr 3N4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726118458; x=1726723258; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=78cgp61viNCbwWsOS5mPogRMJR9sAFu8OFHqjWHCdAI=; b=ACBbe39gtSiM+hTHmoHUgfKEYOb1k48n9U5UPwi9HL1Jsh5d4gbNUoePLJZFjT9RL2 Aww7kHHdIPy8IuTMK8FRtdmonW9MJn4ryMY8lFQFa6GKaGgkXvx3ZWoyh0anQ95ULZl0 oD3Xvl4fwD2ueXvraiu69arKyBqsF95LH9eWE3euHO84WV7ClAg0fHevrrtxDvvprrhm 4Z2Yps721KdFDUxLbZ5j/hzeM3oVh0R7lUyVWB8TcAPNCtWa6VnRYHIs7IDYM6ZjUua0 so0AfywiAO0yM/q4kegyXFnUDOFW3RCDMQDpXTCd95v0QDNraF66MJ7ay210nRFohZyc mn+w== X-Gm-Message-State: AOJu0YwHGP0EEWkTmCZEgHvJlfAFpFb6yjkhJt5NqMX47lT6UxxgznPp wC9sC8BVQgYL0F4qheeNeRFyjCA0uy8nrsTk4gDL1UAQv9dHlhegMPNyUiYoRO4= X-Google-Smtp-Source: AGHT+IFEx5bjq2QGihT1rkZFhaJSJdY2zvgPsdTWLK9pam16Ngltzxc8lqDNnsU4ujH0LoNy95zxfw== X-Received: by 2002:a05:690c:83:b0:64a:7040:2d8e with SMTP id 00721157ae682-6dbb6b984b9mr14611767b3.33.1726118457685; Wed, 11 Sep 2024 22:20:57 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6db9642d024sm9491947b3.4.2024.09.11.22.20.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2024 22:20:56 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_64E2624B-B37C-4A87-B5C2-A0D09AB1A96F" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: [PHP-DEV] Zephir, and other tangents Date: Thu, 12 Sep 2024 01:20:55 -0400 In-Reply-To: Cc: PHP internals To: Hammed Ajao References: <8D420123-4ECF-48FD-A9C3-F80C60457A37@newclarity.net> X-Mailer: Apple Mail (2.3696.120.41.1.10) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_64E2624B-B37C-4A87-B5C2-A0D09AB1A96F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 11, 2024, at 4:43 PM, Hammed Ajao wrote: >=20 > Using WebAssembly (Wasm) for PHP doesn't make much sense. PHP already = runs on its own virtual machine server-side, so adding another VM (Wasm) = would just introduce unnecessary complexity and overhead.=20 Sorry, but I am going to have to call your assertions ill-informed, at = best. Having one VM does not invalidate the value of a different VM = with very different strengths.=20 If using two VMs really made no sense there would not be so many people = running a Lua VM in Java. > Additionally, would this be the LLVM or Cranelift variant of Wasm? TBD > For extensions, Wasm would perform even worse than current = implementations, no matter how it's integrated. Presently, I define = zif_handler function pointers that operate on the current execution = frame and return value, triggered when the engine detects an internal = function (fbc). This approach is as direct as it gets. It is not the performance of integration point but what can be done = within WASM, and that would be able to be done on managed hosts if = incorporated into PHP core. =20 As for use of extensions that are not part of core on a managed host, = some of us in the USA have a saying that relates:=20 "Besides that Mrs. Lincoln, how was the play?" =20 > Suggesting AssemblyScript, especially in this context, seems = illogical. Have you actually worked with WebAssembly and considered = performance implications, or is this based on theoretical knowledge? Admittedly theoretical. =20 Are your objections based on actually working with it, or theoretical = too? > Your point about operator overloading doesn't seem valid either. One cannot validly claim validity or lack of validity of an _opinion_. =20= You can disagree or agree =E2=80=94 as that is how one engages with = opinion =E2=80=94 but an opinion does not beg a proof. > Consider the following: >=20 > ```php > class X { > public function plus(X $that) {} > public function equals(X $that) {} > } > ``` >=20 > In this case, `plus` could represent any behavior, as could `equals`. = If I wanted to, I could implement `plus` to perform what `equals` does = and vice versa. Should we consider methods broken just because their = names can be arbitrary? You are comparing apples and oranges. =20 There are very few standardized method names and the number of potential = method names is combinatorially large. There are a very few number of = operators and each has a well-known meaning with numbers or in boolean = expressions, which means that if you use one you have reduced by one the = scarce resource of operators, assuming they are used in a manner were 99 = out of 100 developers would choose to overload them in the same way (vs. = say 60 out of 100.) But this is just one concern. Read on for other concerns. > PHP already distinguishes between comparison operators for objects: It seems them operator overloading is not needed so much then, right? > `=3D=3D=3D` compares object IDs, while `=3D=3D` compares their = properties. Beyond this, there's little reason to apply an operator to = an object directly. Why would you need to call `$user1 + $user2` or = similar operations on an object?=20 Why would you add $money1 + $money2, or more likely $subtotal *(1+ $tax) = + $shipping? Because it make sense. =20 And my opinion is that is makes sense if done in core, but not if done = in userland. Again, my *opinion*. > What scenario would break by allowing operator overloads? The scenario of reading code and being confused if looking at scalars or = objects, and if objects then being able to find the implementation. The = more unique a method is named, the faster it is to find in a codebase, = even with a really smart IDE like PhpStorm. Now imagine having to search = for the implementation of `+`, and not even knowing if there is such an = override for code that is not type-hinted. Basically operator overloading is one of the subsets of features for = writing DSLs and having watched everyone in the Ruby community write = their own DSLs in their projects they ended up with as many different = languages as they had programming teams, and 99% of those languages were = incomplete and poorly designed. =20 There is something freeing about constraints and it is just my opinion = that PHP having the constraints that you cannot really write DSLs mean = that people end up more often getting work done rather than writing = their own custom DSL.And operator overloads are in this category for me. BTW, the first time I realized this was in the early 90's when I = compared Clipper to FoxPro. Clipper was so much more powerful than = FoxPro as a language. I taught Clipper professionally and I wrote a book = on it. But after the end of that phase of my life I looked back on = Clipper vs. FoxPro and realized that Clipper developers spent lots of = time trying to create their perfect DSL =E2=80=94 myself included =E2=80=94= but because you couldn't do that in FoxPro people just really got a lot = of shit done with FoxPro. > However, consider a case where comparing just one property of an = object (like a hash) is enough to determine equality. Wouldn't it be = great if, without changing any of the calling code, the engine compared = `$this->hash =3D=3D=3D $that->hash` when `$this =3D=3D $that` is = invoked, instead of all properties? No, it would be awful. I would not be able to look at the code and know = what it is actually comparing. =20 And what if I actually want to compare the objects and not the hashes? = What if I did not know the object has an overload for equals and I wrote = code assuming it was comparing objects? > Without operator overloading, I'd have to define an `equals` method = and replace every `$obj =3D=3D $x` call with `$obj->equals($x)`. IMO doing what you'd "have to" do equates to better software = engineering. > Moreover, operator overloading unlocks new possibilities for algorithm = design. For example, you could define complex mathematical operations on = custom objects, enabling you to express algorithms more concisely and = naturally. Imagine implementing vector addition, matrix multiplication, = or symbolic computation directly in PHP. Instead of verbose method calls = like `$vec1->add($vec2)` or `$matrix1->multiply($matrix2)`, you could = use simple and intuitive syntax like `$vec1 + $vec2` or `$matrix1 * = $matrix2`. This is particularly useful for domain-specific algorithms = where overloading enhances readability and performance. Not sure if you read all my comments in this or the prior thread, but I = was arguing that there are *some* good use-cases =E2=80=94 ones that = could easily be standardized across all PHP users =E2=80=94 and those = use-cases would make great features to have in core: vector addition, = matrix multiplication, and symbolic computation fit into those = categories IMO. > Operator overloading isn't just about convenience. It opens the door = to more expressive algorithms, better readability, and reduces = boilerplate code, all while maintaining backward compatibility with = existing PHP behavior. It opens the door to DSLs which opens the door to allowing every team to = have their own unique DSL, and that is why I am against it. But listen, I am just voicing my opinion, and I am only voicing it = because I made a comment about relaxing operators in typedefs and = someone claimed (something like) "that has the same issues as operator = overloading" for which I disagreed. But now because of further replies I = have gone really far down the operator overloading rabbit hole which I = had not intended to go down. =20 On this I have a firmly-held opinion based from well over 30 years of = programming experience, so I am really unlikely to change my opinion. = But it is still just my opinion, I don't have a vote anyway, anyone is = in the right to disagree with me, and AFAIK there is not even an active = RFC currently being discussed where the ones 4[1] and 3[2] years ago = were both declined. =20 So arguing with me about operator overloading is effectively just = tilting at windmills. If you really want userland operator overloading = in PHP so badly, propose another RFC and everyone who wants it will = likely champion it, I will likely argue against it, but maybe it will = finally pass and you'll get what you want. Whatever the case, respectfully, you can disagree with me but please do = not claim my opinion is "invalid" as that is just hubris. -Mike [1] https://wiki.php.net/rfc/userspace_operator_overloading = =20 [2] https://wiki.php.net/rfc/user_defined_operator_overloads = --Apple-Mail=_64E2624B-B37C-4A87-B5C2-A0D09AB1A96F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Sep 11, 2024, at 4:43 PM, Hammed Ajao <hamiegold@gmail.com>= wrote:

Using WebAssembly (Wasm) for PHP = doesn't make much sense. PHP already runs on its own virtual machine = server-side, so adding another VM (Wasm) would just introduce = unnecessary complexity and overhead. 

Sorry, but I am going to have to call your assertions = ill-informed, at best.  Having one VM does not invalidate the value = of a different VM with very different strengths. 

If using two VMs really made no sense there would = not be so many people running a Lua VM in Java.

Additionally, would this be the LLVM or Cranelift variant of = Wasm?

TBD


For = extensions, Wasm would perform even worse than current implementations, = no matter how it's integrated. Presently, I define zif_handler function = pointers that operate on the current execution frame and return value, = triggered when the engine detects an internal function (fbc). This = approach is as direct as it gets.

It is not the performance of integration point but = what can be done within WASM, and that would be able to be done on = managed hosts if incorporated into PHP core.  

As for use of extensions that are not part of core = on a managed host, some of us in the USA have a saying that = relates: 

 "Besides that = Mrs. Lincoln, how was the play?"  

Suggesting AssemblyScript, = especially in this context, seems illogical. Have you actually worked = with WebAssembly and considered performance implications, or is this = based on theoretical knowledge?

Admittedly theoretical.  

Are your objections based on actually working with = it, or theoretical too?

Your point about operator = overloading doesn't seem valid either. =

One = cannot validly claim validity or lack of validity of an _opinion_. =  

You can disagree or agree =E2=80= =94 as that is how one engages with opinion =E2=80=94 but an opinion = does not beg a proof.

Consider the following:

```php
class X {
    public function plus(X $that) {}
    public function equals(X $that) {}
}
```

In this = case, `plus` could represent any behavior, as could `equals`. If I = wanted to, I could implement `plus` to perform what `equals` does and = vice versa. Should we consider methods broken just because their names = can be arbitrary?

You are comparing apples and oranges. =  

There are very few = standardized method names and the number of potential method names is = combinatorially large. There are a very few number of operators and each = has a well-known meaning with numbers or in boolean expressions, which = means that if you use one you have reduced by one the scarce resource of = operators, assuming they are used in a manner were 99 out of 100 = developers would choose to overload them in the same way (vs. say 60 out = of 100.)

But this is just one = concern. Read on for other concerns.

PHP = already distinguishes between comparison operators for objects:

It seems them operator overloading is not needed so = much then, right?

`=3D=3D=3D` compares object IDs, = while `=3D=3D` compares their properties. Beyond this, there's little = reason to apply an operator to an object directly. Why would you need to = call `$user1 + $user2` or similar operations on an object? 

Why would you add $money1 + $money2, or more = likely $subtotal *(1+ $tax) + $shipping?  Because it make sense. =  

And my opinion is that is = makes sense if done in core, but not if done in userland.  Again, = my *opinion*.

What scenario would break by allowing operator = overloads?

The scenario of reading code and being confused if = looking at scalars or objects, and if objects then being able to find = the implementation. The more unique a method is named, the faster it is = to find in a codebase, even with a really smart IDE like PhpStorm. Now = imagine having to search for the implementation of `+`, and not even = knowing if there is such an override for code that is not = type-hinted.

Basically operator = overloading is one of the subsets of features for writing DSLs and = having watched everyone in the Ruby community write their own DSLs in = their projects they ended up with as many different languages as they = had programming teams, and 99% of those languages were incomplete and = poorly designed.  

There is = something freeing about constraints and it is just my opinion that PHP = having the constraints that you cannot really write  DSLs mean that = people end up more often getting work done rather than writing their own = custom DSL.And operator overloads are in this category for = me.

BTW, the first time I realized = this was in the early 90's when I compared Clipper to FoxPro. =  Clipper was so much more powerful than FoxPro as a language. I = taught Clipper professionally and I wrote a book on it.  But after = the end of that phase of my life I looked back on Clipper vs. FoxPro and = realized that Clipper developers spent lots of time trying to create = their perfect DSL =E2=80=94 myself included =E2=80=94 but because you = couldn't do that in FoxPro people just really got a lot of shit done = with FoxPro.

However, consider a case where = comparing just one property of an object (like a hash) is enough to = determine equality. Wouldn't it be great if, without changing any of the = calling code, the engine compared `$this->hash =3D=3D=3D = $that->hash` when `$this =3D=3D $that` is invoked, instead of all = properties?

No, it would be awful.  I would not be able = to look at the code and know what it is actually comparing. =  

And what if I actually want = to compare the objects and not the hashes? What if I did not know the = object has an overload for equals and I wrote code assuming it was = comparing objects?

Without operator overloading, I'd = have to define an `equals` method and replace every `$obj =3D=3D $x` = call with `$obj->equals($x)`.

IMO doing what you'd "have to" do equates to = better software engineering.

Moreover, operator overloading = unlocks new possibilities for algorithm design. For example, you could = define complex mathematical operations on custom objects, enabling you = to express algorithms more concisely and naturally. Imagine implementing = vector addition, matrix multiplication, or symbolic computation directly = in PHP. Instead of verbose method calls like `$vec1->add($vec2)` or = `$matrix1->multiply($matrix2)`, you could use simple and intuitive = syntax like `$vec1 + $vec2` or `$matrix1 * $matrix2`. This is = particularly useful for domain-specific algorithms where overloading = enhances readability and performance.

Not sure if you read all my comments in this or = the prior thread, but I was arguing that there are *some* good use-cases = =E2=80=94 ones that could easily be standardized across all PHP users = =E2=80=94 and those use-cases would make great features to have in core: = vector addition, matrix multiplication, and symbolic computation fit = into those categories IMO.

Operator overloading isn't just = about convenience. It opens the door to more expressive algorithms, = better readability, and reduces boilerplate code, all while maintaining = backward compatibility with existing PHP behavior.

It opens the door to DSLs which opens the door to = allowing every team to have their own unique DSL, and that is why I am = against it.

But listen, I am just = voicing my opinion, and I am only voicing it because I made a comment = about relaxing operators in typedefs and someone claimed (something = like) "that has the same issues as operator overloading" for which I = disagreed. But now because of further replies I have gone really far = down the operator overloading rabbit hole which I had not intended to go = down.  

On this I have a = firmly-held opinion based from well over 30 years of programming = experience, so I am really unlikely to change my opinion. But it is = still just my opinion, I don't have a vote anyway, anyone is in the = right to disagree with me, and AFAIK there is not even an active RFC = currently being discussed where the ones 4[1] and 3[2] years ago were = both declined.
 
So arguing with me about = operator overloading is effectively just tilting at windmills.  If = you really want userland operator overloading in PHP so badly, propose = another RFC and everyone who wants it will likely champion it, I will = likely argue against it, but maybe it will finally pass and you'll get = what you want.

Whatever the case, = respectfully, you can disagree with me but please do not claim my = opinion is "invalid" as that is just hubris.

-Mike

[2] https://wiki.php.net/rfc/user_defined_operator_overloads

= --Apple-Mail=_64E2624B-B37C-4A87-B5C2-A0D09AB1A96F--