Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117395
MIME-Version: 1.0
References: <CAESVnVq80gzujeb_DsfH9hU5Q+YVQcAYF+siLZSiQOC2cxDBqw@mail.gmail.com>
 <1289b56c-e766-4889-bbb2-06abb4e63a6d@www.fastmail.com> <CABdc3WrSUjPSA+XqHv1bGi_1kvr6ampfg4ggS9tZwgRSFpvG=A@mail.gmail.com>
In-Reply-To: <CABdc3WrSUjPSA+XqHv1bGi_1kvr6ampfg4ggS9tZwgRSFpvG=A@mail.gmail.com>
Date: Tue, 22 Mar 2022 11:38:03 +0100
Message-ID: <CAPzBOBMQSEzMeGvS=dJfbPKsYT7JhF5O5hL7WEs-ivE3kgsJ3A@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cc9abd05dacc350d"
Subject: Re: [PHP-DEV] Discussion: String streams
From: landers.robert@gmail.com (Robert Landers)

--000000000000cc9abd05dacc350d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 22, 2022 at 10:41 AM Micha=C5=82 Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> I don't have much to say on that besides that I feel it's a great idea
> and if that can be built with parametrized type streams (not limited to
> strings only)
> then I'd be even more thrilled with such functionality.
>
> Thanks for this idea and I hope it get materialized soon.
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski
>
> pon., 21 mar 2022 o 18:10 Larry Garfield <larry@garfieldtech.com>
> napisa=C5=82(a):
>
> > On Mon, Mar 21, 2022, at 10:23 AM, Sara Golemon wrote:
> > > TL;DR - Yeah, PHP, but what if C++?  Feel free to tell me I'm wrong a=
nd
> > > should feel bad.  THIS IS ONLY IDLE MUSINGS.
> > >
> > > I was reading the arbitrary string interpolation thread (which I have
> > mixed
> > > feelings on, but am generally okay with), and it got me thinking
> > > about motivations for it and other ways we might address that.
> > >
> > > I spend most of my time in C++ these days and that's going to show in
> > this
> > > proposal, and the answer is probably "PHP isn't C++" and that's fine,
> > but I
> > > want you to read to the end, because XSS is perennially on my mind an=
d
> > this
> > > might be one extra tool, maybe.
> > >
> > > PHP internal classes have the ability to handle operator overloads, a=
nd
> > one
> > > use for overloads I quite like from C++ is streaming interfaces.
> Imagine
> > > the following:
> > >
> > > // Don't get hung up on the name, we're a long way from bikeshedding
> yet.
> > > $foo =3D (new \ostringstream) << "Your query returned " <<
> $result->count()
> > > << " rows.  The first row has ID: " >> $result->peekRow()['id'];
> > >
> > > At each << operator, the RHS is "shifted" into the string builder, an=
d
> > the
> > > object instance is returned.  At the end $foo, is still that object,
> but
> > > when it's echoed or cast to string it becomes the entire combined
> string.
> > > As implementation details, we could keep the string as a list of
> segments
> > > or materialize completely, that could also be optimized to not
> > materialize
> > > if we're in an output context since the intermediate complete string =
is
> > > unnecessary.  Don't worry about this for now though.
> > >
> > > That by itself is... curious as an option, but not terribly interesti=
ng
> > as
> > > we DO have proper interpolation and it works just fine, right?
> > >
> > > The reason I'm bothering to introduce this is that we could also buil=
d
> > > contextual awareness into this.  During instantiation we could identi=
fy
> > the
> > > context like:
> > >
> > > $forOuput =3D new \ostringstream\html << "You entered: " <<
> > > $_POST['textarea'];
> > > $forURIs =3D new \stringstream\uri << BASE_URI << '?''
> > > foreach ($_GET as $k =3D> $v) {
> > >   $forURIs << $k '=3D' $v << '&';
> > > }
> > >
> > > These specializations could perform automatic sanitization during the
> > > materialization phase, this could even be customizable:
> > >
> > > $custom =3D new \ostringstream\user( landonize(...) );
> > >
> > > We wouldn't be giving arbitrary operator overloading to the user, onl=
y
> > > arbitrary sanitization.
> > >
> > > Alternatively (or in addition), the point of materialization could be
> > where
> > > we make this decision:
> > >
> > > echo $stream->html();
> > >
> > > ------
> > >
> > > I'd build this in userspace, but of course we don't have operator
> > > overloading, so the API would be a somewhat uglier function call:
> > >
> > > $stream->append("This feels ")->append(FEELING::Sad);
> > >
> > > Maybe the right answer is open the door on user-defined operator
> > overloads,
> > > but my flame retardant suit is in the shop and I don't really need to
> > open
> > > that mixed metaphor.
> > >
> > > -Sara
> >
> > What you're proposing here is:
> >
> > 1. An overloadable operator on objects (via a new magic method or
> > whatever) that takes one argument and returns another a new instance of
> the
> > same class, with the argument included in it along with whatever the
> > object's existing data/context is.
> > 2. Using that for string manipulation.
> >
> > If you spell the operator >>=3D, then point 1 is adding a monadic bind.
> > This has my full support.
> >
> > Using it for string manipulation is fine, although there's a bazillion
> > other things we can do with it that I would also very much support and
> can
> > be done in user space.  Whether or not it makes sense for some of these
> > operations to be done in C instead is up for debate.  Once an arbitrary
> > object can have a socket, that plus monads can push most stream
> operations
> > to user space.
> >
> > Building a "stream wrapper" like thing, or a filter, then becomes some
> mix
> > of object composition and binding.
> >
> >
> > $s =3D new StripTagsStream(new ZlibCompress(FileStream($fileName)) >>=
=3D
> > $htmlString;
> >
> > Which... feels kinda Java clunky.  It would be better if we could chain
> > out the wrapping levels.  Which could potentially just be done in the
> > implementation to allow a stream on the RHS to mean that.
> >
> > public function __bind(Stream|string $s) {
> >   if ($s instanceof Stream) {
> >     return $s->wrapAround($this);
> >   }
> >   // Whatever this object does with a string.
> > }
> >
> > $s =3D new FileStream($fileName) >>=3D new ZlibCompress() >>=3D new
> > StripTagsStream() >>=3D $htmlString;
> >
> > I'm... not sure which direction we'd want them to go in.  Just
> > spitballing.  Some way to automate that pattern would likely be good.
> >
> > But yeah, a native bind operator has my support. :-)
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

But why can't we have generic operator overloading in which case this could
be completely built by libraries in userland?

--000000000000cc9abd05dacc350d--