Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119560
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-156-g081acc5ed5-fm-20230206.001-g081acc5e
Mime-Version: 1.0
Message-ID: <5e4d4fc4-5368-4abf-aa6b-ae964e6a263e@app.fastmail.com>
In-Reply-To: <d22c1618-6e5c-a9c6-b4ee-7fb253e02e9f@cubiclesoft.com>
References: <e352423f-b740-07c9-2c4a-996112e17bbe@cubiclesoft.com>
 <92c4514f-70e3-75c9-7084-9e29641e25e7@gmail.com>
 <7e86a2d2-b971-592c-64e3-e86c13b5be80@cubiclesoft.com>
 <E963ED74-0404-4A5D-9811-8D1E662F764A@gmail.com>
 <84204896-F9CE-4186-8A72-573A0B46FC1D@gmail.com>
 <CAM9Wwz7Si98GDoJHaUKoJtOWt_UzzkjacohP4Z0XdRJsMnOPgg@mail.gmail.com>
 <d22c1618-6e5c-a9c6-b4ee-7fb253e02e9f@cubiclesoft.com>
Date: Wed, 15 Feb 2023 17:24:44 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Working With Substrings
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Feb 15, 2023, at 1:35 PM, Thomas Hruska wrote:
> On 2/15/2023 6:03 AM, Lydia de Jongh wrote:
>> Hi,
>> Very interesting topic! On which I have NO experience =F0=9F=99=88
>>=20
>>=20
>> In some other languages every variable IS an object..... by default.
>>=20
>> As far as I understand, the code above is meant as internal.
>> But what if any variable is a small object.
>> Has this been ever considered? Or would it use too much performance?
>>=20
>> $oString =3D 'my text';
>>=20
>> $oString->toUpper();
>>=20
>> echo $oString;  // 'MY TEXT'
>
> The above represents a significant amount of scope creep but it's=20
> certainly interesting.  So let's explore it a bit and gauge the respon=
se.
>
> The above code will currently throw an error.  Significant global=20
> adoption of such a change will take a fairly long time - probably a=20
> decade, maybe longer.
>
> AFAIK, there is nothing technically preventing the core Zend engine fr=
om=20
> accepting a -> token after a string variable and calling a function th=
at=20
> performs an inline modification of the string.
>
> As a brief test, I just ran the example code through PHP and got:  "PH=
P=20
> Fatal error:  Uncaught Error: Call to a member function toUpper() on=20
> string in test.php:4"  The error message shows that Zend engine clearl=
y=20
> already recognizes toUpper() as an attempted function/method call on a=20
> string...it just doesn't know what to do with it.  So the logic for=20
> supporting -> method calls on strings appears, at least from my very=20
> brief test, to already be mostly in place.  Nice!

*snip*

What you're describing here is "scalar methods", which has been discusse=
d on and off for many years.  The idea has its proponents, but also its =
detractors.  (I'm in the detractor camp, personally, as I think there ar=
e better, more flexible options.)

I would strongly recommend not allowing "faster string manipulation" to =
scope creep into scalar methods, as that will almost guarantee that it n=
ever comes to fruition. :-)  IF scalar methods were to happen, they shou=
ld happen on their own.

--Larry Garfield