Hi,
My answer below.
On 09/01/13 20:57, guilhermebla...@gmail.com wrote:
Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch inste
I'm going to address these question in the proposal I'm working on - once
it's all in writing, I will post for debate.
On Wed, Jan 9, 2013 at 2:57 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> - Should we support nested annotations?
>
> - How [Foo()] will be different from n
On 2013-01-09, Rasmus Lerdorf wrote:
> On 01/09/2013 04:16 AM, Derick Rethans wrote:
>> On Tue, 8 Jan 2013, Rafael Dohms wrote:
>
>>> 1. The syntax is crap: this is solvable, let's find the right syntax
>>
>> Any extra syntax makes the PHP parser more complicated (and arguably
>> slower). I don'
On 09.01.2013 13:12, Derick Rethans wrote:
There is a tokenizer for this already that Greg wrote ages ago in
pecl:
http://pecl.php.net/package/docblock - why can't that be extended to
parse your style of annotations in docblocks?
To be honest; I haven't had the time yet to learn and apply exte
Clint,
If you switch from [] to <> everything works like a charm. =)
Everything was working smoothly on version 2. Version 3 was an attempt to
simplify the patch, but removing tons of things that would pop in a few
time if patch was accepted.
Cheers,
On Wed, Jan 9, 2013 at 3:24 PM, Clint Priest
This version of annotations (attributes?) is much more interesting than
the most recent version, but I could see this syntax as being a problem
if it were allowed to apply to plain functions because then the parser
would have difficulty distinguishing from an array. I suppose the same
could be
Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch instead of on
(sorry for the wording) bitching about the idea.
There're tons of e
Hi!
> @MyApp\Acl({
> "allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}),
> "deny"=@OtherApp\Acl\Deny(default="*", log=true)
> })
I seriously hope it never comes to this in PHP. We're supposed to be
simple language for doing cool stuff on the web, not a serialization
format for ORM m
Hi,
I agree with you on this point, we should not introduce any new
feature if there is no way to deal with largely used extensions like
apc, xdebug or maybe others. The provided implementation is not
supposed to be final (syntax or internal implementation) and I'm sure
there are many improvements
On 01/09/2013 04:16 AM, Derick Rethans wrote:
> On Tue, 8 Jan 2013, Rafael Dohms wrote:
>> 1. The syntax is crap: this is solvable, let's find the right syntax
>
> Any extra syntax makes the PHP parser more complicated (and arguably
> slower). I don't want to have it slower/more complex for some
On Wed, Jan 9, 2013 at 3:48 PM, Benjamin Eberlei wrote:
> On Wed, Jan 9, 2013 at 1:42 PM, Derick Rethans wrote:
>
>> Please, no top posting!!!
>>
>> On Wed, 9 Jan 2013, Vladislav Veselinov wrote:
>>
>> > Taken from the Doctrine documentation:
>> >
>> > > > class User
>> > {
>> > //...
>> >
On Wed, Jan 9, 2013 at 1:42 PM, Derick Rethans wrote:
> Please, no top posting!!!
>
> On Wed, 9 Jan 2013, Vladislav Veselinov wrote:
>
> > Taken from the Doctrine documentation:
> >
> > > class User
> > {
> > //...
> > /**
> > * @ManyToMany(targetEntity="Group")
> > * @JoinTabl
Please, no top posting!!!
On Wed, 9 Jan 2013, Vladislav Veselinov wrote:
> Taken from the Doctrine documentation:
>
> class User
> {
> //...
> /**
> * @ManyToMany(targetEntity="Group")
> * @JoinTable(name="User_Group",
> * joinColumns={@JoinColumn(name="User_id",
>
On Tue, 8 Jan 2013, Rafael Dohms wrote:
> On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote:
>
> > > Everyone I talked to who implemented annotations in docblocks did it
> > > as hack because there is no native support. This is not something that
> > > belongs to docblocks. It would be nice if
Well, Derick,
> And really, nobody can convince me that we would need stuff like:
>
> @MyApp\Acl({
> "allow"=@MyApp\Acl\Allow({"john"="read", "joe"="write"}),
> "deny"=@OtherApp\Acl\Deny(default="*", log=true)
> })
>
> cheers,
> Derick
>
that actually worked quite well in an old ZF1 MVC
Taken from the Doctrine documentation:
wrote:
> On Tue, 8 Jan 2013, Pierrick Charron wrote:
>
>> On 8 January 2013 03:55, Stas Malyshev wrote:
>>
>> > On the contrary, plenty of implementations means there's a need in
>> > this functionality, and it might be a good idea to have one standard
>> >
On Tue, 8 Jan 2013, Mike van Riel wrote:
> As far as I am concerned I'd separate this topic into a DocBlock
> parser (that might take into account the current state of affairs with
> DocBlock Annotations) and actual Annotation support.
Yup - two different things. Something akin an extension tha
On Tue, 8 Jan 2013, Pierrick Charron wrote:
> On 8 January 2013 03:55, Stas Malyshev wrote:
>
> > On the contrary, plenty of implementations means there's a need in
> > this functionality, and it might be a good idea to have one standard
> > implementation if it can cover like 80% of use cases.
On Mon, 7 Jan 2013, Yahav Gindi Bar wrote:
> I don't think that we should dictate the syntax for each application.
> Each application will get the doc-comment annotation and will be able
> to apply on it its own syntax and fancy stuff...
And this is the exact reason why I think it makes no sens
30 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Reflection annotations reader
In my opinion (for however little it matters), code is code, and comments
are comments. They should not mingle.
Annotations, if implemented, should have their own syntax that makes them
code, not an abstra
On Wed, Jan 9, 2013 at 10:29 AM, Leigh wrote:
> In my opinion (for however little it matters), code is code, and comments
> are comments. They should not mingle.
>
> Annotations, if implemented, should have their own syntax that makes them
> code, not an abstraction of a comment.
>
> I already di
In my opinion (for however little it matters), code is code, and comments
are comments. They should not mingle.
Annotations, if implemented, should have their own syntax that makes them
code, not an abstraction of a comment.
I already dislike the fact that getDocComment is there - in my opinion a
On 9 January 2013 01:08, Rasmus Schultz wrote:
> I've started working on a new proposal, but I'm getting hung up on the
> syntax - if we can't use angle brackets anymore, what can we use? Virtually
> every symbol on a standard US keyword is an operator of some sort, does
> that mean those are all
But I can add more.
Filtering
Validation
Form declaration
Database mapping
Joinpoint definitions (AOP)
Service Injection (look at FLOW3)
Testing
etc
Basically everything can define constraints or usage of an element,
behavior, process or nature of an element.
Let me give some individual examples:
On 09.01.2013 02:38, Rasmus Schultz wrote:
A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API,
There is no DocBlock parser in the Reflection API; you can merely
retrieve the T_DOC_COMMENT token.
and
already g
Unfortunately [] is still not usable because it will introduce syntax
ambiguity with short array syntax. The patch we've done for
annotations would require some small change to work on the new master
version but I can take some time to do it if I see some interest in
the proposal. If someone want t
Hi,
At the time Pierrick and I worked on annotations patch, we couldn't use
some of the operators due to many different reasons:
@ = error supressing
[] = short array syntax
{} = scopr creation
: = all sorts of problems you can imagine
& = array referencing
We actually found that <> was allowed,
If we had true annotations, its certainly something the engine could put to
use... See my previous post in this thread.
-Clint
On Jan 8, 2013, at 7:38 PM, Rasmus Schultz wrote:
> To summarize:
>
> A native implementation of PHP-DOC block parser for run-time purposes
> (annotation libraries)
To summarize:
A native implementation of PHP-DOC block parser for run-time purposes
(annotation libraries) is already available in the Reflection API, and
already goes as deep as it needs to - going beyond simply finding and
extracting the docblocks would make little sense, as every annotation
lib
I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? Virtually
every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?
e.g. thinking of concrete possible
Hi internals,
Just like before, people are confusing documentation support with
behavioral support.
No matter what people say, documentation is documentation and code still
behaves the same with and without the comment docblock. When talking about
behavioral marks, removing that piece makes your c
Hi!
> This functionality parses doccomments and doccomments can be obtained
> through various ways. Reflection is only one. Docblocks can just as well
> come from parsing the files. If this would be tightly bound to the
You can also get functions, classes, etc. from parsing the files. But
from in
> If I read this thread correctly then almost everyone agrees that PHPUnit,
> Symfony, ZF, Doctrine, etc, all use annotations in the DocBlock because
> there
> is no available alternative that enables them to use annotations.
>
Yes, I understood that too.
As far as I am concerned I'd separate th
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote:
> Hi!
>
>> Everyone I talked to who implemented annotations in docblocks did it
>> as hack because there is no native support. This is not something that
>> belongs to docblocks. It would be nice if you could take a look at the
>> c# doc, there
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev wrote:
> Hi!
>
> > Everyone I talked to who implemented annotations in docblocks did it
> > as hack because there is no native support. This is not something that
> > belongs to docblocks. It would be nice if you could take a look at the
> > c# doc, t
Hi!
> Everyone I talked to who implemented annotations in docblocks did it
> as hack because there is no native support. This is not something that
> belongs to docblocks. It would be nice if you could take a look at the
> c# doc, there are really good concepts there.
I know why they did it, and
On 08.01.2013 18:19, Yahav Gindi Bar wrote:
That's true. But I wish to state my opinion now: the current
annotations
that Doctorine etc. use is a hack. They took the original doc-block
style
comments and use them for storing metadata. that's the reason I think
that
in case we'll implement some
I agree with this very much.
In Doctrine we used Docblocks only because its the only means of
implementing something that closely resembles native annotation support. I
would be happy if we would have a Docblock parser in SPL, so that all
libraries can agree on using its syntax, however ultimately
hi Stas,
On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev wrote:
> Hi!
>
>> I agree, there is a need in this functionality, but all those userland
>> implementations were at the first place made because this
>> functionality was not part of the language. I think docblocks is not
>> the solution, doc
I do use PHP Unit and also Doctrine which uses annotations. And I know
that today because there is no native annotations, the implementation
use docblocks so I can not remove them :) But still if I did not know
anything about PHP and that someone was talking to me about comments,
I would expect my
Hi!
> I agree, there is a need in this functionality, but all those userland
> implementations were at the first place made because this
> functionality was not part of the language. I think docblocks is not
> the solution, doc blocks are just comments, and I would expect any
> code to work the sa
Hi,
Firstly - many apologizes for not follwoing along, couldn't be near my mail
yesterday (university...). Many apologizes for the long response too ;).
> .
> There is already a similar RFC here :) Maybe it could be good to start
> from this one so that we don't have any duplicated RFC ?
>
> http
On 8 January 2013 03:55, Stas Malyshev wrote:
> On the contrary, plenty of implementations means there's a need in this
> functionality, and it might be a good idea to have one standard
> implementation if it can cover like 80% of use cases.
I agree, there is a need in this functionality, but all
On Tue, Jan 8, 2013 at 10:17 AM, Stas Malyshev wrote:
> Hi!
>
> > Why does this need to be part of Reflection? Seems a rather odd place for
> > it IMHO, since it basically hard-codes the functionality into part of the
>
> Reflection is an odd place for functionality that describes attributes
> of
On Tue, Jan 8, 2013 at 11:05 AM, Pierre Joye wrote:
> On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans wrote:
>
> > This belongs in an extension, just like last time we've discussed
> > annotations.
>
> Last time we discussed this area, we discussed almost everything about
> docblock and the like
On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans wrote:
> This belongs in an extension, just like last time we've discussed
> annotations.
Last time we discussed this area, we discussed almost everything about
docblock and the likes but actual annotation. However I do not get
your reasoning, anno
On Sun, 6 Jan 2013, Yahav Gindi Bar wrote:
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I've created an RFC that propose to
Hi!
> Why does this need to be part of Reflection? Seems a rather odd place for
> it IMHO, since it basically hard-codes the functionality into part of the
Reflection is an odd place for functionality that describes attributes
of classes, methods, properties, etc.? ITYM "natural place" - that's
e
hi,
On Sun, Jan 6, 2013 at 10:58 PM, Yahav Gindi Bar wrote:
> Hi internals!
>
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I
On 08.01.2013 09:55, Stas Malyshev wrote:
First of all, there are already plenty of established userland
implementations - so there is really no need for this.
On the contrary, plenty of implementations means there's a need in
this
functionality, and it might be a good idea to have one standa
Hi!
> First of all, there are already plenty of established userland
> implementations - so there is really no need for this.
On the contrary, plenty of implementations means there's a need in this
functionality, and it might be a good idea to have one standard
implementation if it can cover like
I agree with Rasmus on this one.
Userland solutions are enough to support a in-docblock solution today, the
performance gains from making it SPL are too little to matter.
However docblocks are a compromise, and not where these should be.
I do suggest we revive Guilherme's RFC and try once more to
Cof... cof...
https://wiki.php.net/rfc/annotations
Good luck convincing php-src folks.
You'd be my hero.
On Mon, Jan 7, 2013 at 9:50 PM, Rasmus Schultz wrote:
> On parsing annotations in docblocks: please don't.
>
> First of all, there are already plenty of established userland
> implementati
On parsing annotations in docblocks: please don't.
First of all, there are already plenty of established userland
implementations - so there is really no need for this.
Whatever you decide on in terms of syntax, most likely won't satisfy every
the needs of every userland annotation library, so at
On Mon, Jan 7, 2013 at 4:50 PM, Lester Caine wrote:
> Pierre Joye wrote:
>>
>> On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine wrote:
>>>
>>> Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I woul
Pierre Joye wrote:
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard for
quite some time now and I would ask you to take a look at that and use it as
basis for the parsing of DocBlocks.
This als
This is what I was going for. Your idea looks better.
On Mon, Jan 7, 2013 at 4:45 PM, Anthony Ferrara wrote:
> Yahav and all,
>
>
> On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar wrote:
>
>> Hi internals!
>>
>> In one of the discussions (about the "deprecated" keyword, to be specific),
>> it wa
Yahav and all,
On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar wrote:
> Hi internals!
>
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be grea
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine wrote:
> Mike van Riel wrote:
>>
>>
>> At phpDocumentor we have been working on formalizing the PHPDoc Standard
>> for
>> quite some time now and I would ask you to take a look at that and use it
>> as
>> basis for the parsing of DocBlocks.
>
>
> This a
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard for
quite some time now and I would ask you to take a look at that and use it as
basis for the parsing of DocBlocks.
This also forms the basis of many of the IDE in-line help material. Producing
some
> So
> @var String
> @param2/param2("bar")
> Will be array('var' => 'String', 'param2/param2' => '("bar")' );
>
>
Let's make this clear immediately: an associative array as output is not
useful.
That would make it impossible to nest annotations. For example, something
like following wouldn't work i
Dear Yahav,
At phpDocumentor we have been working on formalizing the PHPDoc
Standard for
quite some time now and I would ask you to take a look at that and use
it as
basis for the parsing of DocBlocks.
You can find the document here:
https://github.com/phpDocumentor/phpDocumentor2/blob/devel
Yahav Gindi Bar wrote:
> Though I agree with you that the main problem is the syntax.
> We can extract the entire doc-comment and only isolate between annotations,
> so doc-comment like:
> /**
> * @Route("/")
> * @ORM(Key="foo")
> * @var string
> */
>
> Will be : array( 'Route("/")' => "",
There is already a similar RFC here :) Maybe it could be good to start
from this one so that we don't have any duplicated RFC ?
https://wiki.php.net/rfc/annotations-in-docblock
Pierrick
On 6 January 2013 16:58, Yahav Gindi Bar wrote:
> Hi internals!
>
> In one of the discussions (about the "dep
This is attributes. I saw proposal for attributes that was declined.
I think that the language should contain attributes, but because the lack
of them the Annotations, which's currently used by some FW can be a great
addition.
To tell the troth, even if attributes was implemented in PHP, since the
On Mon, Jan 7, 2013 at 1:11 AM, Sebastian Krebs wrote:
> 2013/1/6 Yahav Gindi Bar
>
> > On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta
> wrote:
> >
> > >
> > > I think that our work is to isolate each annotation so it'll be easy to
> > >> access, then, it'll be easy enough to write the code tha
Just a thought on this, some other languages support attributes which is
similar but could also allow the engine to use them for things. As a quick
example (roughly based on what I've seen in c#) but applied to PHP use case:
class a {
[$date(Nullable)]
public function foo(DateTime $date)
-Clint
On Jan 6, 2013, at 5:11 PM, Sebastian Krebs wrote:
> 2013/1/6 Yahav Gindi Bar
>
>> On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta wrote:
>>
>>>
>>> I think that our work is to isolate each annotation so it'll be easy to
access, then, it'll be easy enough to write the code that
2013/1/6 Yahav Gindi Bar
> On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta wrote:
>
> >
> > I think that our work is to isolate each annotation so it'll be easy to
> >> access, then, it'll be easy enough to write the code that creates
> "complex
> >> annotations", such as constructors and so on,
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta wrote:
>
> I think that our work is to isolate each annotation so it'll be easy to
>> access, then, it'll be easy enough to write the code that creates "complex
>> annotations", such as constructors and so on, in userland.
>>
>
> In fact, there's pro
> I think that our work is to isolate each annotation so it'll be easy to
> access, then, it'll be easy enough to write the code that creates "complex
> annotations", such as constructors and so on, in userland.
>
In fact, there's probably no need (now) to go on and build a full
annotation reader
On Mon, Jan 7, 2013 at 12:24 AM, Lars Strojny wrote:
> Hi Yahav,
>
> Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar :
> [...]
> > In one of the discussions (about the "deprecated" keyword, to be
> specific),
> > it was been said that adding ability to read doc-comment annotation could
> > be hand
Hi Yahav,
Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar :
[...]
> In one of the discussions (about the "deprecated" keyword, to be specific),
> it was been said that adding ability to read doc-comment annotation could
> be handy. Personally, I really think it can be great.
>
> So, I've created a
Hi there,
It would be great to have such a feature in reflection itself, since it
would speed up parsing by a huge lot.
Anyway, I noticed that the proposed syntax is quite different from the one
adopted by Doctrine\Common (therefore by Drupal, Symfony, Typo3, ZF, etc.),
which would probably make i
Hi internals!
In one of the discussions (about the "deprecated" keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think it can be great.
So, I've created an RFC that propose to improve the Reflection extension by
add
75 matches
Mail list logo
