Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88547
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.160.174 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_kXeBiQ4O9u-0mXu47zKt2-c9uQSWGZ4KReTfjzbzT7kw@mail.gmail.com>
References: <CALW=WEBPC2N2tzmU1uB_v93YXLa1MA97=0_q7zP0F6G+uRPDNQ@mail.gmail.com>
	<56095A0C.4070306@cubiclesoft.com>
	<CAFMT4NqaqVX-KHh9iz_R05wxp2h=aajv5RuQGh2EQVSNHoLGaQ@mail.gmail.com>
	<CAEZPtU6cgVrqh0PNYybcrk4_X36m5K=dp280G=7OfzjYBzxJpQ@mail.gmail.com>
	<CAJW__o2727mc+ugUd2NvvYTB-r0dC68dkUOke+oPjwZDtZA+vQ@mail.gmail.com>
	<1443529244.15520.67.camel@kuechenschabe>
	<CAL=_i_kXeBiQ4O9u-0mXu47zKt2-c9uQSWGZ4KReTfjzbzT7kw@mail.gmail.com>
Date: Tue, 29 Sep 2015 15:48:49 +0100
Message-ID: <CAL=_i_nb9r9hfknB+X-+SA2k-k6hQUs1Wh2nFHUwQznDkT83yg@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Kalle Sommer Nielsen <kalle@php.net>, Pierre Joye <pierre.php@gmail.com>, Levi Morrison <levim@php.net>, 
	PHP internals <internals@lists.php.net>, Thomas Hruska <thruska@cubiclesoft.com>, 
	"S.A.N" <ua.san.alex@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a7d6c6a08d70520e3e976
Subject: Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?
From: pthreads@pthreads.org (Joe Watkins)

--001a113a7d6c6a08d70520e3e976
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry, that was all over the place ... was on way out the door ...

What I should have said is that async/await don't directly solve problems,
they are nice calling conventions for async APIs, but the APIs must exist
before we talk about reserving or adding anything else.

The real problem is that there is a lack of nice async API's, this problem
can be solved independently of any syntax, and should be.

Of course, there isn't much of a drive to create such API's internally ...
they might never come ... thankfully projects like icicle, and others, have
us pretty well covered. The fact is that there isn't much to gain by
duplicating that functionality internally, it won't really go remarkably
faster, and there would be far less people able to contribute to their
development.

That's better ...

Cheers
Joe


On Tue, Sep 29, 2015 at 2:52 PM, Joe Watkins <pthreads@pthreads.org> wrote:

> We shouldn't reserve words on a whim ...
>
> async/await doesn't solve any problems for multithreaded programming, at
> all ... it solves problems for asynchronous programming, a different
> concept ... let's not confuse the two ...
>
> As mentioned you don't need any special syntax or reserved words for
> asynchronous execution, these problems are not solved by adding two words
> to the parser. The API's might not be very nice, and there aren't enough =
of
> them, but there is absolutely nothing stopping you writing asynchronous
> code, and there wasn't in PHP4 either ...
>
> Cheers
> Joe
>
> On Tue, Sep 29, 2015 at 1:20 PM, Johannes Schl=C3=BCter <johannes@schluet=
ers.de
> > wrote:
>
>> On Tue, 2015-09-29 at 08:49 +0200, Kalle Sommer Nielsen wrote:
>> >  Hi
>> >
>> > 2015-09-29 7:30 GMT+02:00 Pierre Joye <pierre.php@gmail.com>:
>> > > This model totally failed for us in the past. And given that these
>> keywords
>> > > will be used for anything related to async APIs, let reserve them an=
d
>> put
>> > > our users on the safe side already.
>> >
>> > While I understand the concern, I don't think we should just go
>> > reserve a bunch of keywords if there is no concrete plan an
>> > implementation model, maybe an RFC is having more no votes than yes
>> > votes etc, and we are stuck with 2 keywords that won't be used for
>> > another few years at least
>>
>> I wouldn't block them in the parser. We however could list them in the
>> naming guide http://php.net/manual/en/userlandnaming.php but for keeping
>> this relevant we have to maintain that page :)
>>
>> Async/multi-threading functionality can also be built without keywords
>> using a "future" or "promise" model like C++ or JavaScript.
>>
>> johannes
>>
>
>

--001a113a7d6c6a08d70520e3e976--