Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93086
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
References: <5723F2AE.2020806@garfieldtech.com>
 <d158ceff-b888-604c-387c-942239c0e783@zend.com>
 <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
Message-ID: <7d47c7ab-39d3-2b2d-be88-ebc66176c7a2@gmail.com>
Date: Thu, 5 May 2016 11:34:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <8a7d1e8a-1e9e-0bbd-912a-21201638b989@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------55E7F89EEE7D39C322C6D29F"
Subject: Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal
From: rowan.collins@gmail.com (Rowan Collins)

--------------55E7F89EEE7D39C322C6D29F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Stanislav Malyshev wrote on 05/05/2016 07:48:
>> The key idea of RFC was not to invite another language for meta-data,
>> >but use PHP language itself.
> This is a good way to avoid handling a lot of issue, but what I am
> afraid of is that with this solution, what would happen that people
> start doing exactly that - inventing another languages for metadata.


I tend to agree - what the proposal basically says is "here's a generic 
parser, invent a domain-specific language using that parser". 
Theoretically, people could implement all sorts of weird "operator 
overloading" behaviour:

<<Push($foo >> Translator)>>

<<Pipe($foo|lower|escape)>>

<<Query($foo ?? '//item[id=42]')>>

Do we really need or want that kind of flexibility, just to avoid 
agreeing a specific structure for metadata?

Regards,
Rowan Collins
[IMSoP]


--------------55E7F89EEE7D39C322C6D29F--