Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92701
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.161.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NrAshwagmGr6RcadbnLGoe71huA7yYcLYhW-Yf7ohFHGg@mail.gmail.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
	<CAFMT4NrAshwagmGr6RcadbnLGoe71huA7yYcLYhW-Yf7ohFHGg@mail.gmail.com>
Date: Sun, 24 Apr 2016 21:45:04 +0100
Message-ID: <CA+kxMuShw2D=-i8UgN4xrE3Kr9dVWnxO9Kr_VW7ZrVkaxQ7C4A@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Dmitry Stogov <dmitry@zend.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: danack@basereality.com (Dan Ackroyd)

Hey Levi,


TL:DR, if we can reserve some syntax for annotations that will be used
by the PHP Engine, that would cover my concern.

On 24 April 2016 at 17:57, Levi Morrison <levim@php.net> wrote:

> isn't `@attr()` 100% valid user-land code today that can precede

Er, yes it is! I didn't put too much thought the suggestion. 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.

> how is @attr() different than `<<attr()>>`?

If this RFC passes, someone could implement their own DBC feature
using an annotation similar to:

<<dbc($a + $b > 0, 'InvalidFooArgsException')>>

Which under the current RFC proposal, would just be a standard
annotation as far the PHP Engine is concerned. The
framework/application the person is using would do the work to
implement the DBC feature in userland code.

In two years time when we want to implement dbc in the Engine, we
would need to choose between either:

* using <<dbc(...)>> as the syntax for the PHP internal feature, which
would break userland code where they had chosen the same name we had.

* using a different syntax to the <<...>> one to implement a DBC feature.

* think up a cunning way of adding to the <<...>> syntax that doesn't
break existing code that uses anotations.

Choosing a syntax now that can be expanded for other uses in the
future, is easier to do now, rather than in two years time, when it
would be a BC break.

Hack has implemented some 'special' attributes[1], that are
interpreted by the HHVM Engine. All of those special attributes start
with double underscores.

If we did the same, and reserved (through documentation), that
annotations starting with leading double underscores are reserved for
future expansion, that would allow us to implement them (if we wanted
to) without too many complaints of BC breakage.

i.e.

<<dbc(...)>> // this is a userland implementation
<<__dbc(...)>> // Reserved for PHP internal implementation.

cheers
Dan


[1] https://docs.hhvm.com/hack/attributes/special