Just starting a new thread here to discuss true annotations vs a
DocBlock Parser:
RFC Referenced:
https://wiki.php.net/rfc/annotations
On 1/9/2013 2:09 AM, Peter Cowburn wrote:
On 9 January 2013 01:08, Rasmus Schultz ras...@mindplay.dk wrote:
I've started working on a new proposal, but I'm
Very good RFC !
Annotation might be better than ReflectionAnnotation ?
Possible usage of annotation as keyword instead of an abstract class:
- abstract class seems more logicial
Nested Annotation declaration: Foo(Bar) or Foo(new Bar):
- Foo(Bar) for consistency
Le 09/01/2013 11:53, Clint
On Wed, 9 Jan 2013, Clint Priest wrote:
Just starting a new thread here to discuss true annotations vs a DocBlock
Parser:
RFC Referenced:
https://wiki.php.net/rfc/annotations
On 1/9/2013 2:09 AM, Peter Cowburn wrote:
On 9 January 2013 01:08, Rasmus Schultz ras...@mindplay.dk wrote:
Hi,
I agree here, I think the above, if possible would be best. In my
mind annotations should proabably be limited in scope to class
declarations and thus only before a class keyword, before a property
or method declaration.
In none of those scopes would [ ] be a parsing issue I believe...
Hi internals,
I would like to give you my thoughts about annotations.
An annotation *must not change* the code *behavior* but add a useful
*information* for the users or *tools*.
The syntax used most of the time is very restrictive (such as
Foo('Bar'), DateType('datetime'), MinLength(42)
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps christian.k...@mohiva.comwrote:
Hi,
I agree here, I think the above, if possible would be best. In my
mind annotations should proabably be limited in scope to class
declarations and thus only before a class keyword, before a property
or
Am 09.01.2013 13:03, schrieb Yahav Gindi Bar:
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps
christian.k...@mohiva.comwrote:
Hi,
I agree here, I think the above, if possible would be best. In my
mind annotations should proabably be limited in scope to class
declarations and thus only
On Wed, Jan 9, 2013 at 2:09 PM, Christian Kaps christian.k...@mohiva.comwrote:
Am 09.01.2013 13:03, schrieb Yahav Gindi Bar:
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps christian.k...@mohiva.com
**wrote:
Hi,
I agree here, I think the above, if possible would be best. In my
mind
Annotations can be nested so in this case [Foo([BAR])] there is a big
ambiguity and we can not determine if [BAR] is an array with the BAR
constant in it or an annotation.
Pierrick
On 9 January 2013 05:53, Clint Priest cpri...@zerocue.com wrote:
In none of those scopes would [ ] be a parsing
Regarding syntax... Would this work?
|foo|
|bar( |baz| )|
best regards
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
No please, two symbols for each side looks ugly.
BTW There's number sign (#) which is, as far as I remember, not used in
PHP at all. Could be something like:
#JoinColumn(name=..., type=..., ...)
#Foo(Bar())
Or
#Foo(#Bar())
(should we put a annotation-sign in front of a nested annotation?)
# is an alternative syntax for comments
On 9 January 2013 08:27, Nikita Nefedov inefe...@gmail.com wrote:
#Foo(#Bar())
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The # would be parsed as a comment
Kind Regards
Pierre du Plessis
*Cell*: 072 775 3477
*Fax*: 086 650 4991
*Email*: i...@customscripts.co.za ad...@customscripts.co.za
*www*: http://www.customscripts.co.za
On Wed, Jan 9, 2013 at 3:27 PM, Nikita Nefedov inefe...@gmail.com wrote:
No please,
I think this RFC syntax is outdated. We can remove the whole new syntax and
just make everything between php code that returns the last statement
because of the array short syntax this ends up to be stuff like:
['foo' = bar']
['foo' = foo()]
['foo' = new Foo('bar')]
This would greatly simplify
https://wiki.php.net/rfc/annotations
Perhaps I am blind, but I do not see where in the RFC is defends its
choice to use ``. Every other language I know of uses `@`, and I do
not know of technical reasons why we couldn't use the same symbol.
Annotations wouldn't be able to contain expressions so
Every other language used :: or . for namespaces. The problem with @ is its
definition as error suppression operator, and Guilherme and Pierrick didn't
come up with a solution to stay BC using the @. Additionally some other
languages use [] (which also doesnt work in PHP).
On Wed, Jan 9, 2013 at
be anything that could generate a suppressible error.
Not true:
@ORM\Column()
class Test() {
}
What if there's a function in the ORM namespace called Column.
Is this a supressed error of a function call and we've missed the ;
or is it an annotation?
--
PHP Internals - PHP Runtime
On Wed, Jan 9, 2013 at 8:20 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Levi,
On Wed, Jan 9, 2013 at 10:15 AM, Levi Morrison morrison.l...@gmail.com
wrote:
https://wiki.php.net/rfc/annotations
Perhaps I am blind, but I do not see where in the RFC is defends its
choice to use ``. Every
Levi
Maybe I'm a complete fool, but since annotations aren't executed (they
are declarative only), this should cause no problems.
You're not a fool. And the point is not that they are executed, but because
they are nearly syntactically identical to executable code. So parser and
readability
they are nearly syntactically identical to executable code.
nearly is the keyword there. They lack the ending semi-colon. Sure,
this might mean PHP has to actually use an abstract syntax tree, but
that's long overdue in my opinion. I know others disagree. This is
only tangentially related, so I
On 1/9/13 9:31 AM, Levi Morrison wrote:
they are nearly syntactically identical to executable code.
nearly is the keyword there. They lack the ending semi-colon. Sure,
this might mean PHP has to actually use an abstract syntax tree, but
that's long overdue in my opinion. I know others
Let's not subsidize the headache drug manufacturers with PHP syntax
decisions. :-)
Too late.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Before we all bikeshed on the syntax, shouldn't we be figuring out the
feature-set first?
Over in PHP-FIG, we've found it useful to audit the existing market to
see what's in use. That doesn't dictate decisions we make, but it can
be instructional. Eg, if we find that most annotation-using
On Wed, Jan 9, 2013 at 5:20 PM, Larry Garfield la...@garfieldtech.comwrote:
On 1/9/13 9:31 AM, Levi Morrison wrote:
they are nearly syntactically identical to executable code.
nearly is the keyword there. They lack the ending semi-colon. Sure,
this might mean PHP has to actually use an
Hi!
Just starting a new thread here to discuss true annotations vs a
DocBlock Parser:
RFC Referenced:
https://wiki.php.net/rfc/annotations
Didn't look into it in detail but one note - can we please come up with
something that doesn't look like broken HTML?
--
Stanislav Malyshev,
Why don't we pick a commonly used annotation symbol like * then? It
currently can't start an expression so there's not an ambiguity (that
I can think of).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
26 matches
Mail list logo
