Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain webstart.fr from 209.85.161.174 cause and error)
MIME-Version: 1.0
Sender: pierrick@webstart.fr
In-Reply-To: <CAFKaYMq4Z+Lv3j+ds=pc6iOK43fNCaz0cJX3tOt1WA0k2hpv5Q@mail.gmail.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
	<CAFMT4NrAshwagmGr6RcadbnLGoe71huA7yYcLYhW-Yf7ohFHGg@mail.gmail.com>
	<571DD94B.3060604@zend.com>
	<571E63D0.8080800@gmail.com>
	<9c24f969-cb0e-cb46-a23c-6e06e7de7d79@gmail.com>
	<571E7C08.6010309@gmail.com>
	<571F1B95.9030203@zend.com>
	<CAFKaYMqbPiHsWJpSKLgV-Yvtpwz9MiA_U243=NRtaTtOrXs+fw@mail.gmail.com>
	<CAFKaYMpzuA6suSDascKppspwAnqSpVviY9J01B=NqbpUfBUqJA@mail.gmail.com>
	<CAFKaYMpTM9VNkAUAKPqbDFjf+3AgJu1Yw1x_rR5-TOp64AjctA@mail.gmail.com>
	<CY1PR0201MB17867883CAF70F426788E531BF630@CY1PR0201MB1786.namprd02.prod.outlook.com>
	<CAOfKkdQa7o-WUh5PB+KVnKxwwjtCXuMX0MQUrnOycNCXfePrCg@mail.gmail.com>
	<CAFKaYMq4Z+Lv3j+ds=pc6iOK43fNCaz0cJX3tOt1WA0k2hpv5Q@mail.gmail.com>
Date: Wed, 27 Apr 2016 01:25:04 -0400
Message-ID: <CAOfKkdQ3t6qgKKFdR4ipaUSh53f1X8UTT2+SXHeoid4QwY7QXQ@mail.gmail.com>
To: Dominic Grostate <codekestrel@googlemail.com>
Cc: PHP internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=001a114f0e8cd2ca7b053170a1df
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: pierrick@adoy.net (Pierrick Charron)

--001a114f0e8cd2ca7b053170a1df
Content-Type: text/plain; charset=UTF-8

Hi all,

First of all thanks dmitry for your great work and for bringing the RFC
back to life.

I think it would be great to allow users to define their own annotations
and give them some structure (what the annotation is made of). For example
let's say I apply an annotation to define that a property is a string with
a length. In the proposed RFC I will have something like this :

class Foo {
    <<MyAnnotation\StringLength(10)>>
public string $bar;
}

But how could i know for example that StringLength can take an extra
parameters I would have to read the code of the annotation framework see
how it parse, use it etc... But if I can define the structure (this is a
quickly invented pseudo syntax and I'm not proposing it)

annotation MyAnnotation\StringLength {
private int $length;
private string $comment = "Default value";
}

With this definition I know that the Annotation take 2 parameters one int
and one string, that the comment has a default value and can be omitted
etc...

Also what I dislike about using a simple array with no definition is that
you can't annotate an annotation since there is no definition. I know it
can look complex but think about the power you can add to the system. It
would help us solve some problems that could not be solved (or at least I
can't see any way of doing it) if you can't have a definition you can't
attach behaviour/metadata to it.

Here are some problems we could solve (those are just examples)

1. Are annotations inhereted or not ? Some will say yes, some now but I
think they actually both make sense. For example we could imagine that if I
annotate a method of my interface as deprecated I want it to be inhereted
because all implementations are, but author annotation should not be
inherited because I'm not necessarily the author of the implementation. So
we could say that annotations are by default not inherited and we could
have an <<inherited>> annotation

<<inherited>>
annotation deprecated {
}

annotation author {
public string $name;
public string $mail;
}

2. Is a specific kind of annotation applicable to only one kind of
statement or multiple ? JIT don't make sense on a property...

<<Target(Target::METHOD)>>
annotation jit {
}

3. Current version of the RFC propose that we could either have AST or to
execute the AST but we could imagine to get both

annotation assert {
<<AST>>
public ast\node $node;
public string $message;
}

Again, this is just a couple of quick ideas, but this would make things
less magic/obscure with a definition and far more flexible. If we agree
that we want a definition we could work on how to create this definition
(we could use some stuff from the old Annotations RFC
https://wiki.php.net/rfc/annotations?rev=1302087566) to update this one
with a new syntax or use interface as proposed in the first implementation

class Deprecated implements Annotation {
}

Maybe

Pierrick

--001a114f0e8cd2ca7b053170a1df--