Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92723
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <571DEC9E.80407@zend.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CAESVnVrNqpqsTUCdHiQi8j3d4KVz8ZqRh6pEVJegR-EsmFN3_g@mail.gmail.com>
	<571BA0F0.2030400@fleshgrinder.com>
	<571C82A7.2060706@fleshgrinder.com>
	<CAEPJdum9BdM2B04d6Jp0_YtD=YZa1pPjUD3H5ZC4RRYkw_t1jA@mail.gmail.com>
	<571CB44C.1000704@fleshgrinder.com>
	<CAEPJdunm-YukXgSV5OWigiWX02Sw9Nz=GvLgJJN4Fq-j-hjZcA@mail.gmail.com>
	<571CBD1E.7020103@fleshgrinder.com>
	<571DD2A3.2020106@zend.com>
	<CAEZPtU4hdWDHD-z96-sT=d8KEk3bVVrpjMRFbkvQ2Z5QvdNFZg@mail.gmail.com>
	<571DEC9E.80407@zend.com>
Date: Mon, 25 Apr 2016 12:28:57 +0100
Message-ID: <CAL=_i_=8cLe+8OiBc8=-1GkWCGxEy-n2phhbpfV=n0fSKju-bA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP internals <internals@lists.php.net>, 
	Benjamin Eberlei <kontakt@beberlei.de>, Sara Golemon <pollita@php.net>
Content-Type: multipart/alternative; boundary=001a1143312c7d415605314d7b8c
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: pthreads@pthreads.org (Joe Watkins)

--001a1143312c7d415605314d7b8c
Content-Type: text/plain; charset=UTF-8

Morning internals,

    This morning I attempted to prototype a dbc extension.

    In my opinion, the patch, or internals, are not fit for the intended
purpose.

    At the moment, the *only* way to perform meta programming is going to
be in userland. This is going to make it prohibitively slow, and rather
pointless.

    None of the compiler API is exported: This means that AST is almost
useless to internals unless it's a constant expression.

    There is a problem with zend extensions and fcall handlers, which we
are not sure how to fix.

    Working with AST is easy, working with opcodes directly is not.

    Before we can have this, we must work on the AST API and allow
extensions to transform AST with much better hooks than we have at the
moment.

    I was excited to start working with this .. at the moment, I'm -1.

Cheers
Joe

PS. If anyone is interested http://github.com/krakjoe/dbc was my first
attempt at interacting with the patch.




On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> On 04/25/2016 12:44 PM, Pierre Joye wrote:
>
>> hi Dmitry,
>>
>> Awesome work! Thanks.
>>
>> I do like you keep what was discussed last time. Make the basics
>> available and leave the rest to the applications (doctrine or other).
>>
>> I feel too that how the apps will interact with may need some more
>> discussions but other commented on it so I won't interfer here :).
>>
> I've collected the most interesting feedback at
> https://wiki.php.net/rfc/attributes#open_issues
> And I'm going to correct RFC and implementation rethinking these questions.
>
> Thanks. Dmitry.
>
>
>>
>> On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>>
>>> The proposed by you "@..." syntax just won't fit into PHP grammar,
>>> because @
>>> used as silence operator.
>>>
>>> Attribute, syntax is taken from HHVM. I don't see a big reason to
>>> introduce
>>> more fragmentation into PHP world.
>>>
>> Also see https://docs.hhvm.com/hack/attributes/syntax and I fully
>> agree with Dmitry here. It makes no sense now to go with our own
>> syntax.
>>
>> If any of the hhvm developers are around, we may get some feedbacks
>> about their current APIs (using getAttributes) and if they would like
>> to change one thing or another. That could (or must) part of the PHP
>> specifications.
>>
>> Cheers,
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1143312c7d415605314d7b8c--