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
On 9 January 2013 01:08, Rasmus Schultz ras...@mindplay.dk 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
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
On Wed, Jan 9, 2013 at 10:29 AM, Leigh lei...@gmail.com 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
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 abstraction
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 sense
On Tue, 8 Jan 2013, Pierrick Charron wrote:
On 8 January 2013 03:55, Stas Malyshev smalys...@sugarcrm.com 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
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 that
Taken from the Doctrine documentation:
?php
class User
{
//...
/**
* @ManyToMany(targetEntity=Group)
* @JoinTable(name=User_Group,
* joinColumns={@JoinColumn(name=User_id,
referencedColumnName=id)},
* inverseJoinColumns={@JoinColumn(name=Group_id,
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 app I developed, and
On Tue, 8 Jan 2013, Rafael Dohms wrote:
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
Please, no top posting!!!
On Wed, 9 Jan 2013, Vladislav Veselinov wrote:
Taken from the Doctrine documentation:
?php
class User
{
//...
/**
* @ManyToMany(targetEntity=Group)
* @JoinTable(name=User_Group,
* joinColumns={@JoinColumn(name=User_id,
On Wed, Jan 9, 2013 at 1:42 PM, Derick Rethans der...@php.net wrote:
Please, no top posting!!!
On Wed, 9 Jan 2013, Vladislav Veselinov wrote:
Taken from the Doctrine documentation:
?php
class User
{
//...
/**
* @ManyToMany(targetEntity=Group)
*
On Wed, Jan 9, 2013 at 3:48 PM, Benjamin Eberlei kont...@beberlei.dewrote:
On Wed, Jan 9, 2013 at 1:42 PM, Derick Rethans der...@php.net wrote:
Please, no top posting!!!
On Wed, 9 Jan 2013, Vladislav Veselinov wrote:
Taken from the Doctrine documentation:
?php
class User
{
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
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
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 metadata. If we
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
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
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
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
On 2013-01-09, Rasmus Lerdorf ras...@lerdorf.com 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'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 new
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
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
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
hi,
On Sun, Jan 6, 2013 at 10:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com 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
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
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
On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans der...@php.net 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
On Tue, Jan 8, 2013 at 11:05 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jan 8, 2013 at 10:57 AM, Derick Rethans der...@php.net wrote:
This belongs in an extension, just like last time we've discussed
annotations.
Last time we discussed this area, we discussed almost everything
On Tue, Jan 8, 2013 at 10:17 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On 8 January 2013 03:55, Stas Malyshev smalys...@sugarcrm.com 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
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 ?
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 same
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 Stas,
On Tue, Jan 8, 2013 at 7:28 PM, Stas Malyshev smalys...@sugarcrm.com 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
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
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
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 we
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
On Tue, Jan 8, 2013 at 10:37 PM, Stas Malyshev smalys...@sugarcrm.com 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
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 this
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
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
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
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
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 ras...@mindplay.dk wrote:
To summarize:
A native implementation of PHP-DOC block parser for run-time purposes
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, so
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
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
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
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
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine les...@lsces.co.uk 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
Yahav and all,
On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com 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
This is what I was going for. Your idea looks better.
On Mon, Jan 7, 2013 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Yahav and all,
On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi internals!
In one of the discussions (about the deprecated keyword,
Pierre Joye wrote:
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine les...@lsces.co.uk 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
On Mon, Jan 7, 2013 at 4:50 PM, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
On Mon, Jan 7, 2013 at 9:30 AM, Lester Caine les...@lsces.co.uk wrote:
Mike van Riel wrote:
At phpDocumentor we have been working on formalizing the PHPDoc Standard
for
quite some time now and I
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
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 ras...@mindplay.dk wrote:
On parsing annotations in docblocks: please don't.
First of all, there are already plenty of established
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
Hi Yahav,
Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.ya...@gmail.com:
[...]
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,
On Mon, Jan 7, 2013 at 12:24 AM, Lars Strojny l...@strojny.net wrote:
Hi Yahav,
Am 06.01.2013 um 22:58 schrieb Yahav Gindi Bar g.b.ya...@gmail.com:
[...]
In one of the discussions (about the deprecated keyword, to be
specific),
it was been said that adding ability to read doc-comment
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 that
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com 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,
2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com 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
-Clint
On Jan 6, 2013, at 5:11 PM, Sebastian Krebs krebs@gmail.com wrote:
2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com wrote:
I think that our work is to isolate each annotation so it'll be easy to
access, then,
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)
On Mon, Jan 7, 2013 at 1:11 AM, Sebastian Krebs krebs@gmail.com wrote:
2013/1/6 Yahav Gindi Bar g.b.ya...@gmail.com
On Mon, Jan 7, 2013 at 12:41 AM, Marco Pivetta ocram...@gmail.com
wrote:
I think that our work is to isolate each annotation so it'll be easy to
access, then,
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
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 g.b.ya...@gmail.com wrote:
Hi internals!
In one of the
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(/)' = , 'ORM(Key=foo)' = ,
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:
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 if the
74 matches
Mail list logo
