Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125514 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 3B1EF1A00BD for ; Wed, 11 Sep 2024 21:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1726090489; bh=mWSNjslGzVbCAllYUZms301BsX++pdwvwJUace95dSg=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=k/FXnTgaEourIyh6bLdvZnPZ0yX6qgqSol4jtMjKQHlW5GpZ1VqdnWbZJA/TXateJ f2X8zio+gR4mUFuNGm7O4QyyW6i+JrUKDymqtl67nBzeNYXzcgSm8Gbi1KwH/HqthY GCGYeQPlw6WQ/rWtdEgPzDecvhjFO6XHW7XCshgrBmo6v2TMyPyox7jkb2uObkBERw 2WXV89t8GWB2VqmR77pfn5vZjJFwzLQiHJcWmh20F+IXIuTXfcfe7/ckE6EfHEeRP+ YXI0Drx5FT3/Ary1KCqkPUqLKeYvoEmH13a8/4F2AgrlbnCsKiGhFhkHhfyw+4Baii HkDSvT114x6Ag== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B9DCB180078 for ; Wed, 11 Sep 2024 21:34:48 +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_DNSWL_NONE, 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-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 ; Wed, 11 Sep 2024 21:34:48 +0000 (UTC) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-e1d2cf4cbf1so423431276.1 for ; Wed, 11 Sep 2024 14:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1726090366; x=1726695166; 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=L/iLRL+HmF2vZKAyKpyquRQljzBdp5ONIALjBeailCM=; b=G8uhOXkuGrvKQUnd0VwNyDY8Pftgj0IbNEie0S94yqfSDkdU7cbxUR6bUZ2O/LHfM5 /Tq8ZQXbDgI0M16Dv5lpCB7PkhiVlJ0D6upd9OaOjrOcEiu9OVQIIvNr5GJaaEYG3T9F m59y/vE+p10PfVthNeit7fBZ40qW+DME/GB7N03ko5olszl3FA9IdH5yzmSFKPYi9kpV 25IuxOPPMOL7L9ObLwQaONKHvLO2LYQx9kAZtq+Q79WKKfMgR4HaOtX2BOceqeJPUPNP IQ0jXr9btsWxDV/63Ivwq83c9Fk7aeIO2kiJgzD4Hg7VXExxWXIgwI7cCjAUhOoBOyaT K6ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726090366; x=1726695166; 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=L/iLRL+HmF2vZKAyKpyquRQljzBdp5ONIALjBeailCM=; b=Zcwdd4L8m0RCCu0C/6oVdbn3SNbOINqEfvPB/TqsytAQoIAVZ2z6kOF/zSMgqVE94Q O0tfv3b5HDAWc2jrkx77tu3vtEWNSWFAyUwO6YFHOPkpkBqFjzw6deTUabXbQFKcJHJ+ ky58oH019iCciTuyGqCAnflsUNaIV7EglZO1fhECn8zPTC4ec9zjkk8sZhbfFgyLFP+o JOm+6p18L1Thm6/+WjOW6AvvwWYtPgtHzUVZosoYAskaxruzrHOod4Lu03w3bk8F5BM0 k5dMFQJ6NJF8q2gn7uPcL0HNb+6ZVAmICkOKNBXQQQ1lnPOxvVdc0J9xySlr37XuycA5 GHfw== X-Gm-Message-State: AOJu0Yww8nth+ADAt3FF+9lnfGcc4dFL1XwYKAgD9GBC94c2bg7lj0sU X+w3gW3AxI5Y57Z5NIOZz90RJG1uytx2Gdj1HIWGNAMB7gF+thXi6uIUagHhvWLnWCmk9pEaRkD + X-Google-Smtp-Source: AGHT+IFZbiraq5ITG+25mg1lsEq6InTSszqxhF/yuX9zbSFbVbVLWsMXXM0pC/XALvth6e+gQP4fMQ== X-Received: by 2002:a05:6902:2b06:b0:e17:bf26:b812 with SMTP id 3f1490d57ef6-e1d9dba6e52mr946566276.23.1726090365573; Wed, 11 Sep 2024 14:32:45 -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 3f1490d57ef6-e1d7bbc1ffcsm818169276.53.2024.09.11.14.32.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2024 14:32:44 -0700 (PDT) Message-ID: <411C39E3-8C18-49DB-BC63-749B876270CC@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B401E94C-BB99-4BC5-B02D-7D46801CF7E2" 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: Wed, 11 Sep 2024 17:32:43 -0400 In-Reply-To: Cc: internals@lists.php.net To: "Rowan Tommins [IMSoP]" 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=_B401E94C-BB99-4BC5-B02D-7D46801CF7E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 11, 2024, at 4:55 PM, Rowan Tommins [IMSoP] = wrote: > On 11 September 2024 20:12:53 BST, Mike Schinkel = wrote: >>> It also risks conflicting with a future language feature that = overlaps, as happened with all native functions marked as accepting = string automatically coercing nulls, but all userland ones rejecting it. = Deprecating that difference has caused a lot of friction. >>=20 >> That is a little different in that it was a behavior that occurred in = both core and userland whereas only allowing operator overloading in = core would mean there would be not userland differences that could = conflict. >=20 > Historically, that's what we had for scalar parameters. All the way = back in PHP 4 (I think), the engine had a function called = "zend_parse_parameters" (ZPP), which took the PHP values a user = provided, and either converted them to the desired C type, or rejected = them. In effect, it allowed functions defined in extensions to declare = scalar typed parameters. >=20 > Then in PHP 7, we added scalar type declarations for parameters in = userland functions, and had to work out how they fitted with those = internal functions. Part of the motivation for the strict_types toggle = was to manage their behaviour; and userland functions require explicit = nullable types, whereas ZPP historically coerced nulls regardless. >=20 > Anything we let extensions do could end up with the same dilemma = later: do we match userland to existing extension behaviour, change = extension behaviour, or live with an awkward inconsistency? There are several levels of hypotheticals in your stated concern, so = yes, if we make all regrettable decisions then we possibly have a = problem. But if we allow several levels of hypotheticals to be criteria = for every decision we make then we can probably find an argument against = any improvement. =20 That said, not doing this seems to matter more to you than doing it = matters to me, so I relent. >> WebAssembly has a deny-by-default design so could be something to = seriously consider for extensibility in PHP. Implementations start with = a full sandbox[2] and only add what they need to avoid those kinds of = concerns.=20 >=20 > The problem is that second part: in order to be useful for writing a = PHP extension, what would we need to let through the sandbox? Initially, only scalar parameters and scalar return values. (Stop and = contemplate this for a moment, please.) Then we can consider "letting through" more in future RFCs as we all = learn more about using WASM and so that each thing we add can be well = considered. >> I think that actually supports what I was saying; people would = gravitate to only doing in an extension what they cannot do in PHP = itself, and over time if PHP itself improves there is reason to migrate = more code to PHP. =20 >>=20 >> But there can still be reasons to not allow some thing in userland. = Some things like __toArray. >=20 > I think there's ideas pulling in opposite directions here: on the one = hand, using the difficulty of building extensions as a deliberate "speed = bump" to avoid people using features "badly"; but on the other hand, = wanting to reduce the difficulty of building extensions. That is one way to look at it, but not the only way and not the way I = was looking at it. Let's say the effort to write something in PHP is 1 and the effort to = write in C is 100 using arbitrary units where 100 means almost nobody = ever does it. My argument considers 100 being too high a bar, but maybe = 50 or 25 is low enough so as to not open the floodgates but still make = it easy enough that people actually do it occasionally as clearly even = 25 is many times harder than 1. And no need to bikeshed those numbers. I was using arbitrary numbers to = try and illustrate a concept, nothing more. BTW, I was not looking at it as a "speed bump," I was looking at it as = the fact that features in core are written in C, not PHP. > I think the latter is a more noble goal, and one way to help is to = make it less *necessary* to build extensions, by adding to the core = language the things you currently need extensions to do. Things like = efficient string buffers and binary stream manipulation, or attributes = and magic methods to override object behaviour. That is one way to consider it, and one I would definitely like to see.=20= But I still do not think you can optimize out all need for low level = languages by adding userland features. =20 For example, how do we add a feature that allows for efficient looping? = Certainly we can optimize the loops themselves; we already have with = functions like `array_map()`, but there would still be need to context = switch between C and PHP callable and zvals. That context switching is = probably at least an order of magnitude more time consuming than a pure = single loop iteration and memory location update in WASM, C, etc. Or do = you envision some way to optimize running code in loops, and storage and = access of data in byte arrays for which I am not seeing? To summarize, I think PHP would benefit from: 1. Adding WASM for simple low-level extensibility that could run on = shared hosts for things that are just not possible in PHP as described a = few paragraphs prior, and where we could enhance functionality over = time, 2. Constantly improving PHP the language, which is what you are solely = advocating for over extensibility, 3. Enabling some parts of core =E2=80=94 definitely some newer functions = and classes, and maybe some existing ones =E2=80=94 to be implemented in = userland PHP that would ship embedded in PHP core to make maintenance = easier and enable more people to potentially contribute to core,=20 4. Allow operator overloading for classes in core where the community = agrees it makes sense, but if that is a bridge too far then I would be = happy if we never allow operator overloading at all, and=20 5. Typedefs FTW! -Mike= --Apple-Mail=_B401E94C-BB99-4BC5-B02D-7D46801CF7E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Sep 11, 2024, at 4:55 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:
On 11 September 2024 20:12:53 BST, Mike Schinkel <mike@newclarity.net>= wrote:
It also risks conflicting with a future = language feature that overlaps, as happened with all native functions = marked as accepting string automatically coercing nulls, but all = userland ones rejecting it. Deprecating that difference has caused a lot = of friction.

That is a little = different in that it was a behavior that occurred in both core and = userland whereas only allowing operator overloading in core would mean = there would be not userland differences that could = conflict.

Historically, that's what we had = for scalar parameters. All the way back in PHP 4 (I think), the engine = had a function called "zend_parse_parameters" (ZPP), which took the PHP = values a user provided, and either converted them to the desired C type, = or rejected them. In effect, it allowed functions defined in extensions = to declare scalar typed parameters.

Then in = PHP 7, we added scalar type declarations for parameters in userland = functions, and had to work out how they fitted with those internal = functions. Part of the motivation for the strict_types toggle was to = manage their behaviour; and userland functions require explicit nullable = types, whereas ZPP historically coerced nulls regardless.

Anything we let extensions do could end up = with the same dilemma later: do we match userland to existing extension = behaviour, change extension behaviour, or live with an awkward = inconsistency?

There are several levels of hypotheticals in your = stated concern, so yes, if we make all regrettable decisions then we = possibly have a problem.  But if we allow several levels of = hypotheticals to be criteria for every decision we make then we can = probably find an argument against any improvement.  

That said, not doing this seems to matter more to = you than doing it matters to me, so I relent.

WebAssembly has a = deny-by-default design so could be something to seriously consider for = extensibility in PHP. Implementations start with a full sandbox[2] and = only add what they need to avoid those kinds of concerns.

The problem is that second part: = in order to be useful for writing a PHP extension, what would we need to = let through the sandbox?

Initially, only scalar parameters and scalar return = values. (Stop and contemplate this for a moment, please.)

Then we can consider "letting through" more in = future RFCs as we all learn more about using WASM and so that each thing = we add can be well considered.

I think that actually supports what I was = saying; people would gravitate to only doing in an extension what they = cannot do in PHP itself, and over time if PHP itself improves there is = reason to migrate more code to PHP.  

But there can still be reasons to not allow some thing in = userland. Some things like __toArray.

I think there's ideas pulling in opposite directions here: on = the one hand, using the difficulty of building extensions as a = deliberate "speed bump" to avoid people using features "badly"; but on = the other hand, wanting to reduce the difficulty of building = extensions.

That is one way to look at it, but not the only = way and not the way I was looking at it.

Let's say the effort to write something in PHP is = 1 and the effort to write in C is 100 using arbitrary units where 100 = means almost nobody ever does it. My argument considers 100 being too = high a bar, but maybe 50 or 25 is low enough so as to not open the = floodgates but still make it easy enough that people actually do it = occasionally as clearly even 25 is many times harder than = 1.

And no need to bikeshed those = numbers. I was using arbitrary numbers to try and illustrate a concept, = nothing more.

BTW, I was not looking = at it as a "speed bump," I was looking at it as the fact that features = in core are written in C, not PHP.

I think the = latter is a more noble goal, and one way to help is to make it less = *necessary* to build extensions, by adding to the core language the = things you currently need extensions to do. Things like efficient string = buffers and binary stream manipulation, or attributes and magic methods = to override object behaviour.

That is = one way to consider it, and one I would definitely like to = see. 

But I still do not think = you can optimize out all need for low level languages by adding userland = features.  

For example, how do = we add a feature that allows for efficient looping? Certainly we can = optimize the loops themselves; we already have with functions like = `array_map()`, but there would still be need to context switch between C = and PHP callable and zvals. That context switching is probably at least = an order of magnitude more time consuming than a pure single loop = iteration and memory location update in WASM, C, etc. Or do you envision = some way to optimize running code in loops, and storage and access of = data in byte arrays for which I am not seeing?

To summarize, I think PHP would benefit = from:

1. Adding WASM for simple = low-level extensibility that could run on shared hosts for things that = are just not possible in PHP as described a few paragraphs prior, and = where we could enhance functionality over time,

2. Constantly improving PHP the language, which is = what you are solely advocating for over extensibility,

3. Enabling some parts of core =E2=80=94 = definitely some newer functions and classes, and maybe some existing = ones =E2=80=94 to be = implemented in userland PHP that would ship embedded in PHP core to make = maintenance easier and enable more people to potentially contribute = to core, 

4. Allow operator overloading for classes in core = where the community agrees it makes sense, but if that is a bridge too = far then I would = be happy if we never allow operator overloading at all, = and 
5. Typedefs FTW!

-Mike
= --Apple-Mail=_B401E94C-BB99-4BC5-B02D-7D46801CF7E2--