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
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,
On Wed, Jan 9, 2013 at 5:20 PM, Larry Garfield wrote:
> 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 sy
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 p
> 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
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 disagre
> 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
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 w
On Wed, Jan 9, 2013 at 8:20 AM, Anthony Ferrara wrote:
> Levi,
>
> On Wed, Jan 9, 2013 at 10:15 AM, Levi Morrison
> 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 other language I know of
> 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 Developm
Levi,
On Wed, Jan 9, 2013 at 10:15 AM, Levi Morrison 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 other language I know of uses `@`, and I do
> not know of technical reasons why we couldn't use
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
> 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 s
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
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
*www*: http://www.customscripts.co.za
On Wed, Jan 9, 2013 at 3:27 PM, Nikita Nefedov wrote:
> No please, two symbols for each side looks ugly.
> BTW T
# is an alternative syntax for comments
On 9 January 2013 08:27, Nikita Nefedov wrote:
> #Foo(#Bar())
--
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 annotatio
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
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 wrote:
> In none of those scopes would [ ] be a parsing issue I believe...
-
On Wed, Jan 9, 2013 at 2:09 PM, Christian Kaps wrote:
> Am 09.01.2013 13:03, schrieb Yahav Gindi Bar:
>
>> On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps > >**wrote:
>>
>> Hi,
>>>
>>>
>>> I agree here, I think the above, if possible would be best. In my
>>>
mind annotations should proababl
Am 09.01.2013 13:03, schrieb Yahav Gindi Bar:
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps
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, befor
On Wed, Jan 9, 2013 at 1:57 PM, Christian Kaps 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.
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) etc
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...
Th
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 wrote:
> > > I
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: )> or :
- )> for consistency
Le 09/01/2013 11:53, Clint Priest a écrit :
Just
26 matches
Mail list logo
