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
> 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
> -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
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
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
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
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';
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
> 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
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
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,
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
> 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
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
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
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
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
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
>> 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
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
> 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
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
> 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
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
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
> 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!
> 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
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
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
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 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 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
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 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
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 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
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 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 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 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 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
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?
42 matches
Mail list logo
