Hello!
There are at least three of the RFC for native work with annotations.
https://wiki.php.net/rfc/reflection_doccomment_annotations
https://wiki.php.net/rfc/annotations-in-docblock
https://wiki.php.net/rfc/annotations
I would like to know how plans in PHP 7 support annotations in the code?
On 3 November 2014 13:56, Alex Sky wrote:
> Hello!
>
> There are at least three of the RFC for native work with annotations.
> https://wiki.php.net/rfc/reflection_doccomment_annotations
> https://wiki.php.net/rfc/annotations-in-docblock
> https://wiki.php.net/rfc/annotations
>
> I would like to k
On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
> There are no current concrete plans and currently nothing being seriously
> discussed (at least, not publicly; I don't know if anyone has anything in
> pipeline that they haven't announced yet). The three RFCs you linked above
> are all basica
On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
>
> On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
>
> > There are no current concrete plans and currently nothing being
seriously
> > discussed (at least, not publicly; I don't know if anyone has anything
in
> > pipeline that they haven't ann
On 11/03/2014 05:26 PM, Pierre Joye wrote:
> On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
>>
>> On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
>>
>>> There are no current concrete plans and currently nothing being
> seriously
>>> discussed (at least, not publicly; I don't know if anyone
On 11/3/14, 10:37 AM, Stefan Neufeind wrote:
On 11/03/2014 05:26 PM, Pierre Joye wrote:
On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
There are no current concrete plans and currently nothing being
seriously
discussed (at least, not
On Mon, Nov 3, 2014 at 10:39 AM, Larry Garfield wrote:
> On 11/3/14, 10:37 AM, Stefan Neufeind wrote:
>>
>> On 11/03/2014 05:26 PM, Pierre Joye wrote:
>>>
>>> On Nov 4, 2014 1:24 AM, "Jonah H. Harris" wrote:
On Mon, Nov 3, 2014 at 9:11 AM, Chris Wright wrote:
> There are
Nothing magical in the annotations no, they very obvious.
It gives you the to declare logic and meta data.
I do not like annotated in comments, I like the implementation of
annotation in C#
2014-11-04 0:49 GMT+02:00 Levi Morrison :
> On Mon, Nov 3, 2014 at 10:39 AM, Larry Garfield
> wrote:
> > O
On Nov 4, 2014 8:50 AM, "Levi Morrison" wrote:
> Whether the annotation is in a comment or not, the idea of changing
> behavior at runtime based on the annotation is pretty magical. I
> highly discourage using this type of feature whether it's in a comment
> or not.
>
> I will certainly vote no o
Hi!
> As I do consider personal tastes important, there are times where we should
> listen to our users.
It would be nice to take "paving the walkways" approach, but last time
we tried, IIRC we've got into something very over-engineered. Maybe if
we try again with more restricted scope (i.e. not
On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev wrote:
> Hi!
>
>> As I do consider personal tastes important, there are times where we should
>> listen to our users.
>
> It would be nice to take "paving the walkways" approach, but last time
> we tried, IIRC we've got into something very over-enginee
On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye wrote:
> On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev
> wrote:
> > Hi!
> >
> >> As I do consider personal tastes important, there are times where we
> should
> >> listen to our users.
> >
> > It would be nice to take "paving the walkways" approach, b
On Nov 4, 2014 8:54 PM, "Benjamin Eberlei" wrote:
>
> On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye wrote:
>>
>> On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev
wrote:
>> > Hi!
>> >
>> >> As I do consider personal tastes important, there are times where we
should
>> >> listen to our users.
>> >
>>
On Tue, Nov 4, 2014 at 12:20 PM, Pierre Joye wrote:
>
> On Nov 4, 2014 8:54 PM, "Benjamin Eberlei" wrote:
> >
> > On Tue, Nov 4, 2014 at 11:28 AM, Pierre Joye
> wrote:
> >>
> >> On Tue, Nov 4, 2014 at 4:21 PM, Stas Malyshev
> wrote:
> >> > Hi!
> >> >
> >> >> As I do consider personal tastes im
Hi!
It would be nice to take "paving the walkways" approach, but last time
> we tried, IIRC we've got into something very over-engineered. Maybe if
> we try again with more restricted scope (i.e. not trying to put a DSL
> for describing arbitrarily complex data structures into it :) it would
> be
Hi!
> PHP7 has a wonderful parser, maybe it's possible to provide a general
> syntax for annotations with userland hooks for arbitrary data. This
> approach can give a tool for framework developers to define a node visitor
> for annotations. Alternative way is to define simple key-value storage an
> On 4 Nov 2014, at 10:54, Benjamin Eberlei wrote:
>
> I agree with Stas that a much simpler approach is probably realistic.
>
> beginning pure speculation here, i see a short array like syntax like:
>
> [foo="bar", bar="baz", baz=["key": "value"]]
> function annotated_fn() {}
>
> Maybe even
Hi!
> All projects mentioned in this thread use:
> http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html
> That makes a pretty good base spec.
Reading it, it looks pretty big - strictly typed values, named
parameters, default constructors linked to properties, support for en
Hi!
> The approach for annotations that I like best would actually be not
> annotations, but Python-style decorators. They’re very simple, but
> very powerful. They would allow you to do annotations, but also add
> extra functionality to functions.
For python-style decorators, at least the way th
> Reading it -
> http://doctrine-common.readthedocs.org/en/latest/reference/annotations.html -
> it looks pretty big - strictly typed values, named
> parameters, default constructors linked to properties, support for enum
> types, support for typed arrays, separate constant syntax within
> annotat
On 04.11.2014 17:34, Andrea Faulds wrote:
> In Python, a decorator is a function (or callable object), and you use one
> like this:
>
> @some_decorator(foo, bar)
> def myfunc():
> # function source code here
I wonder how feasible it would be to add something like this and allow
e
> On 4 Nov 2014, at 18:27, Stas Malyshev wrote:
>
> For python-style decorators, at least the way they work in Python, we'd
> need to organize our function tables differently, as Python just
> replaces the function with another one while decorating, and I'm not
> sure it'd be as easy to do with
If this is difficult, you can do in PHP 7.0 simple realization
annotation/facades, in versions 7.x to develop and refine.
Most importantly, define the syntax and semantics annotation/facades, for a
version of PHP 7.0
Demand in annotation/facades is very high, ~80% of all popular frameworks
their
>> In Python, decorators are very
>> powerful for modifying function behavior (i.e., attaching pre/post
>> conditions to functions or doing some things phpunit does is really
>> easy) but it is too much for just attaching data.
FWIW (and I apologize if this is just adding to the noise), one of the
Hi,
As one of the original authors of both Doctrine Annotations and previous
RFC of native Annotations in PHP, I can go thoroughly on every specific
detail about challenges of design decisions to make.
Primarily, I do not see docblocks as the right place to store class'
metadata information. Meta
On 04/11/14 20:18, guilhermebla...@gmail.com wrote:
> Primarily, I do not see docblocks as the right place to store class'
> metadata information. Metadata != Comments.
We use comment wrappers in many places to hide secondary material from
other processes. Just rename docblocks -> metadata ... wha
Just as a note: /** and /* are already treated differently by the
parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present
in opcache).
Anyway, metadata/annotations/whatever you want to call them should be
seperated from comments and verbal descriptions on a
syntax level, not just by s
Hi!
> Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
I personally regard this as a kind of superstition. There's nothing
wrong with extending what can be in comments. In fact, Javascript was
officially "HTML comment" for years, an
On 04/11/14 21:24, Sebastian B.-Hagensen wrote:
> Just as a note: /** and /* are already treated differently by the
> parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present
> in opcache).
>
> Anyway, metadata/annotations/whatever you want to call them should be
> seperated from comme
> On 4 Nov 2014, at 21:31, Stas Malyshev wrote:
>
>> This brings the next piece of the puzzle. We have to update lexical and
>> semantical understanding of PHP. Taking Java's approach (@) does not
>> work in PHP, because it conflicts with error supression. Same thing
>
> Except for the mental c
Hi,
By dealing with annotations in docblocks will force the Annotations parser
to *much* smarter than you imagine.
Currently in Doctrine Annotations implementation, @param and @Param are
considered different not only by first character to be uppercased, but
rather because a class also exist in th
Sorry, I forgot to add references to how we fixed emails handling. It got
split in 2 places:
- Initial root level annotation
https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L350
- Subsequent root level annotations
https://github.com/doctrine/annot
Hi Guilherme,
On 4 November 2014 23:47, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Sorry, I forgot to add references to how we fixed emails handling. It got
> split in 2 places:
>
> - Initial root level annotation
>
> https://github.com/doctrine/annotations/blob/master/lib/Do
> On 5 Nov 2014, at 14:02, Marco Pivetta wrote:
>
> I'm not sure if we need that sort of syntax and opinionated approach: I like
> Benjamin's approach better, and it is also simpler and still very easy to use
> even in our context (doctrine).
>
> For example, this alternative approach perfect
2014-11-05 17:02 GMT+03:00 Marco Pivetta :
> For example, this alternative approach perfectly fits the current
> doctrine/annotations use-case:
>
> use Doctrine\ORM\Mapping\Entity;
> use Doctrine\ORM\Mapping\Table;
> use Doctrine\ORM\Mapping\Id;
> use Doctrine\ORM\Mapping\GeneratedValue;
> use Doc
I think keeping this just like an array definition in a property would make
this both simple and flexible.
You can even improve on Marcos example with a class having constants:
namespace Doctrine\ORM\Mapping\Annotations;
class ORM
{
const ENTITY = 'Doctrine\ORM\Mapping\Annotations\Entity';
On 11/4/14, 3:31 PM, Stas Malyshev wrote:
Hi!
Primarily, I do not see docblocks as the right place to store class'
metadata information. Metadata != Comments.
I personally regard this as a kind of superstition. There's nothing
wrong with extending what can be in comments. In fact, Javascript
On 11/5/14, 9:15 AM, Alexander Lisachenko wrote:
2014-11-05 17:02 GMT+03:00 Marco Pivetta :
For example, this alternative approach perfectly fits the current
doctrine/annotations use-case:
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Table;
use Doctrine\ORM\Mapping\Id;
use Doctrin
Marco Pivetta wrote on 05/11/2014 14:02:
For example, this alternative approach perfectly fits the current
doctrine/annotations use-case:
use Doctrine\ORM\Mapping\Entity;
use Doctrine\ORM\Mapping\Table;
use Doctrine\ORM\Mapping\Id;
use Doctrine\ORM\Mapping\GeneratedValue;
use Doctrine\ORM\Mappin
> -Ursprüngliche Nachricht-
> Von: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Gesendet: Mittwoch, 12. November 2014 17:21
> An: internals@lists.php.net
> Betreff: Re: [PHP-DEV] Annotation PHP 7
>
> Marco Pivetta wrote on 05/11/2014 14:02:
> > For example
> One problem with using *just* array syntax, without any new keyword or
> symbols,
> is that it is extremely close to being existing valid syntax. This may well
> cause problems in the parser,
> and would certainly be confusing to users.
Not sure how sacred is `$`, but it could be a good candid
That might just work, but it's still close to currently possible code.
Why don't we use something that would currently produce a parse error
and is not as close to valid code
as the examples above?
<<< Annotation('abc'), foo >>> // Used <<< as it's different from
T_SL, but it works for hack, so m
42 matches
Mail list logo
