Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93216 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14263 invoked from network); 11 May 2016 08:42:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 May 2016 08:42:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.176 cause and error) X-PHP-List-Original-Sender: pthreads@pthreads.org X-Host-Fingerprint: 209.85.161.176 mail-yw0-f176.google.com Received: from [209.85.161.176] ([209.85.161.176:33247] helo=mail-yw0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A1/F3-28272-880F2375 for ; Wed, 11 May 2016 04:42:49 -0400 Received: by mail-yw0-f176.google.com with SMTP id t10so40712918ywa.0 for ; Wed, 11 May 2016 01:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pthreads-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tjY+EDINwHeJKLkMKbGaAvsalzFTuhbU4YrbQPbVQks=; b=tjkrHUc6z1JPe2qM9N32Y48+fGDFS4S+vFK0px0RAVCRynrRvqp5e/81OluiAkqYah IOrHVYKs6D2gqmipNKlE15FHa6tfZtp8r5oZBt5QVbxF4OfWbrLDpTEnHJOuTDB0S3xA eIKhib0GZq/GKI8zUAgXoWLjFGZ8Xl1GbJhienHCujvwIvw8NyaZuajIz3nDeGMjlfig gzOiihTV9ZepCovvF+O2C/atYxoB9D6Qlh32ct0+VBhyvZOpLJnO5GZXDlNfjwFFAV/i t6PziccvGYYd8aySp5tRT3x7fRfQvTuXkuFB/YetzhK0jQZqwR5/UE+whGp99C8e92eS boqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tjY+EDINwHeJKLkMKbGaAvsalzFTuhbU4YrbQPbVQks=; b=dim1gMV73lbl7MfR4tTRQOZ61JGFIyaCm2N20b12zhWNbWAzIwSBUo1VxIMd9zvk7Y ZD/suUWYEn6Bvd4PD8TF1MEvKczG3wcwIDwweAE4UjuQ9YO41hyMpothV9MtkIZH0k/T yEBxwECOqlDvFSHoDxyMuSCg3eQsi/lpTC7dIl6pKCX602cFawC3ceI6EmsE/5tP1lZb 8PizuuQXX9EUFGRFW6/lQL9zWWt3bQr8MSJnVTdIO/6Z3xNW2rfPvzE34FPNrxIXzVnd +fPPwHQYqilrSKORSC19PaGZiJxlIpPymSxSAh6eXIInXxF3UUOeo9vm2//oED1bN42Y qlaQ== X-Gm-Message-State: AOPr4FWTqj7nevNCVeQWZ18m4dgEPq3iP3inDB/0Ieb/X/+CCnWktyJ2EVXs+sdqTqrGIB3+qfEgGv15xi/VDA== MIME-Version: 1.0 X-Received: by 10.37.4.214 with SMTP id 205mr817637ybe.27.1462956166184; Wed, 11 May 2016 01:42:46 -0700 (PDT) Received: by 10.129.109.67 with HTTP; Wed, 11 May 2016 01:42:46 -0700 (PDT) X-Originating-IP: [165.120.173.102] In-Reply-To: <001d497d-0117-b337-422b-7192cbed3070@zend.com> References: <8d5d1c42-832d-4406-6bb5-dbf3fc02c364@telia.com> <95ccaf31-11de-8efb-13ba-038d36a6c466@zend.com> <001d497d-0117-b337-422b-7192cbed3070@zend.com> Date: Wed, 11 May 2016 09:42:46 +0100 Message-ID: To: Dmitry Stogov Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= , PHP internals Content-Type: multipart/alternative; boundary=001a11c039c49bbc5105328d0648 Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes From: pthreads@pthreads.org (Joe Watkins) --001a11c039c49bbc5105328d0648 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dmitry, > Except the fact, that doc-comment content don't have to conform to any rules Nor does an attributes value that is just a string, that isn't validated by compiler ... it doesn't *have* to conform to any rules. That's exactly what people are voting for though, that seems to be what people want :s I desperately do not want that. I don't see the remarkable difference (although there is obviously difference) between attributes that are just strings or constant values and doc comments. > and you have to parse it and extract the necessary part of meta information every time you need it. You know that's not really true, there are already hooks and mechanisms to "compile" strings in doc comments, I used them literally yesterday ... I used them in anticipation that we would get a superior solution some time soon ... it now looks like we will not :( I don't want to invent ways to parse code, or extract it from anywhere ... we have a whole engine, an entire folder of code dedicated to that, it is nonsensical not to utilize it. Cheers Joe On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov wrote: > > > On 05/11/2016 09:57 AM, Joe Watkins wrote: > > Dmitry, > > > but it's possible to get the same power translating string values of > attributes into AST in the hooks. > > Aware. > > Enough of the complexity is already the responsibility of the consumer of > the attributes. > > It's already possible to get strings (and so AST) from doc comments, we > don't need anything new if that's all you want to do. > > Essentially, moving something from doc comments to <> makes zero > sense to me. > > > Except the fact, that doc-comment content don't have to conform to any > rules, and you have to parse it and extract the necessary part of meta > information every time you need it. It's not a big problem to do this usi= ng > Doctrine library, but how are you going to do this in a compiler hook? > > > > Cheers > Joe > > On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov wrote: > >> >> >> On 05/11/2016 09:02 AM, Joe Watkins wrote: >> >> Morning Dmitry, >> >> > On the other hand simple string may be parsed into AST with just one >> additional call to ast\compile_string(). >> >> You're not really suggesting that I write my tools in user land, are you >> ? It's me, Joe :)ce >> >> >> At first days of RFC discussion Sara pointed on over-design regarding AS= T. >> I saw sense in here comments and updated RFC. >> >> >> I *only* want attributes as they were originally proposed, and I can't >> vote to reflect that. >> >> As discussed in private, what I want is attributes, as originally >> proposed, and a hookable compiler; Anything else is not good enough. >> >> >> Personally, I'm for AST as well, but it's possible to get the same power >> translating string values of attributes into AST in the hooks. >> >> Thanks. Dmitry. >> >> >> >> Cheers >> Joe >> >> >> >> On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov < >> dmitry@zend.com> wrote: >> >>> Hi Joe, >>> >>> The sense in native support for AST is questionable. >>> >>> >>> On one hand this allows syntax verification. >>> >>> >>> On the other hand simple string may be parsed into AST with just one >>> additional call to ast\compile_string(). >>> >>> >>> Thanks. Dmitry. >>> >>> >>> ------------------------------ >>> *From:* Joe Watkins >>> *Sent:* Wednesday, May 11, 2016 7:46:09 AM >>> *To:* Bj=C3=B6rn Larsson >>> *Cc:* Dmitry Stogov; PHP internals >>> *Subject:* Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes >>> >>> Morning Dmitry, >>> >>> I'm not really happy with the voting options here. >>> >>> I would not vote in favour of a patch that does not include support >>> for AST, that's a completely different feature. >>> >>> As it is, I have to vote yes in favour of AST, but it may be counte= d >>> as a vote in favour of attributes without AST ... >>> >>> This doesn't seem right ... I don't want attributes without AST, an= d >>> there is no voting option to reflect that. >>> >>> Cheers >>> Joe >>> >>> On Tue, May 10, 2016 at 11:09 PM, Bj=C3=B6rn Larsson < >>> bjorn.x.larsson@telia.com> wrote: >>> >>>> Den 2016-05-11 kl. 00:00, skrev Dmitry Stogov: >>>> >>>>> >>>>> >>>>> On 05/11/2016 12:29 AM, Bj=C3=B6rn Larsson wrote: >>>>> >>>>>> Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov: >>>>>> >>>>>> Hi internals, >>>>>>> >>>>>>> >>>>>>> I've started voting on "PHP Attributes" RFC. >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://wiki.php.net/rfc/attributes >>>>>>> >>>>>>> >>>>>>> In my opinion, "PHP Attributes" might be a smart tool for PHP >>>>>>> extension, but it's not going to be the end of the world, if we dec= ided to >>>>>>> live with doc-comments only. >>>>>>> >>>>>>> >>>>>>> Thanks. Dmitry. >>>>>>> >>>>>>> Thanks for the good work. Regarding naming, I googled >>>>>> "PHP attributes" vs "PHP annotations" and looking at the >>>>>> result, my view is that that Annotation is a better naming >>>>>> then Attributes. Any hope in changing it? >>>>>> >>>>> >>>>> The more I listen to arguments of adepts of existing PHP annotation >>>>> systems, the more I think, that "PHP attributes" is the right name fo= r this >>>>> proposal. >>>>> This feature is not just for PHP annotation systems. >>>>> >>>> >>>> Thats a fair point, so Annotation it's not. Still, when I hear PHP >>>> attributes I associate it with class / function attributes. Maybe >>>> just a question getting used to the naming. Hm, wonder if PHP >>>> directives could have been an option? >>>> >>>> Regards //Bj=C3=B6rn >>>> >>>> >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: >>>> http://www.php.net/unsub.php >>>> >>>> >>> >> >> > > --001a11c039c49bbc5105328d0648--