Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92728
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
To: internals@lists.php.net
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
 <CAFMT4NrAshwagmGr6RcadbnLGoe71huA7yYcLYhW-Yf7ohFHGg@mail.gmail.com>
 <CA+kxMuShw2D=-i8UgN4xrE3Kr9dVWnxO9Kr_VW7ZrVkaxQ7C4A@mail.gmail.com>
Message-ID: <571E0D99.2060202@gmail.com>
Date: Mon, 25 Apr 2016 13:29:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CA+kxMuShw2D=-i8UgN4xrE3Kr9dVWnxO9Kr_VW7ZrVkaxQ7C4A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: rowan.collins@gmail.com (Rowan Collins)

Dan Ackroyd wrote on 24/04/2016 21:45:
> The point
> I was trying to make is that it explicitly says that "this is a
> userland attribute", rather than using the generic <<...>> syntax,
> which we might want to use for non-userland attributes at some point.

I think framing the problem as "engine vs userland" is misleading; what 
you are actually saying is "how do we avoid name collisions?"

There's currently no difference in syntax between userland and engine 
functions and classes, and *that is a good thing*, because it means you 
can transparently apply polyfills, create C / Zephir extensions to 
replace performance-sensitive functions, etc. The same could be done for 
annotations - if it's possible to create a userland DBC library, then 
why shouldn't it be able to polyfill the same syntax as an engine one?

As mentioned elsewhere, in an OO implementation of annotations, the 
existing namespace hierarchy could be used (which includes the \php\ 
reservation, which we've never taken advantage of). If it's not, we are 
left with naming conventions.

I would suggest that even if we don't have objects representing the 
annotations, "\" should be allowed, and encouraged, in their names. 
Thus, *by convention*, attributes would be prefixed with at least a 
vendor name ("<<Doctrine\Foo>>", etc).

PHP could reserve "__" and "php\" for future internal use, but also 
semi-reserve the global namespace, as described here: 
http://php.net/manual/en/userlandnaming.rules.php

 > PHP owns the top-level namespace but tries to find decent descriptive 
names and avoid any obvious clashes.

If somebody creates a userland library that uses <<DBC\Require(...)>>, 
it's up to them to deal with the consequences if PHP later implements an 
incompatible version, just as it would be if they wrote a function 
called dbc_require(), or DBC::require().

Regards,
-- 
Rowan Collins
[IMSoP]