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
+1
I totally agree with Leigh.
In my opinion comments should not be abused for any logic. This is the reason
I've never used the annotations for Doctrine, although it is a nice feature.
-Original Message-
From: Leigh [mailto:lei...@gmail.com]
Sent: Wednesday, January 09, 2013 9:30 AM
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:
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
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 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,
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
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,
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?)
We should probably be referring to this type of syntax as attributes
rather than annotations since annotations are currently defined in
docblock comments and are recognized by certain software and utilities.
Whereas annotations have no effect on compilation or at runtime,
attributes do have
# 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,
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)
*
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
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
{
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
I've opened voting for the zend_parse_parameters() improvements RFC.
You can now go to https://wiki.php.net/rfc/zpp_improv#voting
Regards
--
Gustavo Lopes
--
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
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
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!
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
Hi!
class a {
[php:Param($s) = StringLength(4, ErrorMessage='Parameter $s length
cannnot exceed 4.', ErrorLevel=E_USER_ERROR)]
public function foo($s) { ... ]
}
What this is supposed to do?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
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
Rasmus
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level change, any implementation that doesn't also include an
APC diff, or
On Wed, 9 Jan 2013, Anthony Ferrara wrote:
Rasmus wrote:
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level change, any
On 01/09/2013 09:03 AM, Anthony Ferrara wrote:
Rasmus
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level
On Wed, Jan 9, 2013 at 6:06 PM, Derick Rethans der...@php.net wrote:
On Wed, 9 Jan 2013, Anthony Ferrara wrote:
Rasmus wrote:
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of
Hi!
While I do see your point, to me it's less of an issue that it breaks
APC, and more of an issue that APC's functionality is not in core.
You are confusing specific extension with functionality. The problem is
not that specific extension (APC) is not in core, but that the proposal
makes
Hi!
It was a plan in the past, I think we should just do it - now.
If you mean moving the directory from pecl to ext/ - that's fine as long
as maintainers commit to keeping it in shape (last time, I remember, 5.4
support was lagging). If you mean more tight integration - see my
previous email
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Frankly,
On 01/09/2013 09:45 AM, Anthony Ferrara wrote:
PHP NEEDS a vision. It needs something to guide development. Not everyone
will agree with it. And that's the point. It levels the playing field for
contributions and discussions. Rather than every developer playing for
themselves and saying I
On 1/9/13 12:09 PM, Rasmus Lerdorf wrote:
On 01/09/2013 09:45 AM, Anthony Ferrara wrote:
PHP NEEDS a vision. It needs something to guide development. Not everyone
will agree with it. And that's the point. It levels the playing field for
contributions and discussions. Rather than every
2013/1/9 Anthony Ferrara ircmax...@gmail.com
Stas,
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Frankly, I'm getting sick and tired of seeing these recurring themes of
PHP is not
Amaury,
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Frankly, I'm getting sick and tired of seeing these recurring themes of
PHP is not java and I never want this. If you never want
Hi!
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalys...@sugarcrm.com
mailto:smalys...@sugarcrm.com wrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
I admire your politeness and ability to
On Wed, Jan 9, 2013 at 12:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
you're
On Wed, 9 Jan 2013, Stas Malyshev wrote:
It was a plan in the past, I think we should just do it - now.
If you mean moving the directory from pecl to ext/ - that's fine as
long as maintainers commit to keeping it in shape (last time, I
remember, 5.4 support was lagging). If you mean more
Stas,
It is a recurring theme because it's true. You are right that every
language needs a vision, and PHP's vision is being simple and practical
and focused on the web. PHP is what people use to get their first site
off the ground. PHP is what a web designer learns when he/she wants to
go
On 01/09/2013 11:48 AM, Anthony Ferrara wrote:
Rasmus: A general purpose scripting language with a focus on web
development
You: being simple and practical and focused on the web
While they both have web in them, they provide very different goals and
metrics with which to gauge
Stas, perhaps you haven't noticed, but you are regularly derailing
discussions. I know that there are at least a few other people reading
the mailing list who tire of your behavior.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Just a thought here, but perhaps what PHP needs now is a working group
that works together to do some basic management of PHP as a language,
take into account what the users are wanting, talking about, requesting
and setting a vision and direction and make plans for what will and
won't and
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
I was just looking into C# attributes at the time since I had used them
in the past.
It was a loose translation to something for php from the example on this
page:
http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.stringlengthattribute.aspx
In essence the example
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 1/9/13 1:55 PM, Clint Priest wrote:
Just a thought here, but perhaps what PHP needs now is a working group
that works together to do some basic management of PHP as a language,
take into account what the users are wanting, talking about, requesting
and setting a vision and direction and make
On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
The algorithm behaves very poorly in this case because at each position
of the text, all the substrings starting there and with size between m
and n (where m is the size of the smallest pattern and n is the
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).
On 10 January 2013 03:00, Anthony Ferrara ircmax...@gmail.com wrote:
Well, the point is that there are two ways of voicing your dislike. You can
say I never want this or other rhetoric, which helps nobody else but to
understand that you don't want it. Or you can be a little bit more civil
and
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
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM counterpart Doctrine.
Both of which are serious drivers of the PHP community. It's
even potentially spreading to Zend Framework:
On Wed, Jan 9, 2013 at 2:48 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Am I guilty of being abusive? Absolutely. But I hope the abusiveness that I
portray at least tries to be constructive (if it's not always, I'm sorry).
From the Merriam-Webster dictionary:
a·bu·sive
/əˈbyo͞osiv/
(1)
On Thu, Jan 10, 2013 at 4:05 AM, Tyler Sommer somme...@gmail.com wrote:
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM counterpart Doctrine.
Both of which are serious drivers of the PHP community. It's
even potentially
On 10 January 2013 10:05, Tyler Sommer somme...@gmail.com wrote:
Annotations are already a part of PHP. They are widely used in one of the
most prolific frameworks, Symfony, and it's ORM counterpart Doctrine.
To explain what I meant by PHP, since I think we're arguing
semantics there: I mean
Great points, Adam. I disagree with this one feature being excluded but I
do agree that just because something is in the userland doesn't necessarily
mean it should be in the core-- making my point rather moot.
Cheers.
On Wed, Jan 9, 2013 at 6:28 PM, Adam Harvey ahar...@php.net wrote:
On 10
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.
I wonder how Annotations is
Also talking about widely used support, I wonder about how
SplDoubleLinkedList, SplInt, SplMaxHeap and all these classes that have
very specific usages, just like also data structure readers like
json_decode, parse_ini_file are part of the core while others also used as
much as these ones
Hi!
You just proved my point with your reply. PHP doesn't have a vision. The
two people in this thread who have provided what they thought were
visions don't agree. And that's a problem.
If you mean that there would be some vision document that prevents
disagreement and decides arguments once
Hi!
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
I can answer only for myself of course, but I don't have any single
criteria. I look at the feature, how it can be used, how it can be
abused, how it would be seen by experienced PHP
Is there any official/doctrinal list of file types for a GIT/SVN ignore
list when working on a PECL extension? I've been snooping around and
found the following (from
http://stackoverflow.com/questions/85353/best-general-svn-ignore-pattern) but
was wondering if there was any ignore list that
guilhermebla...@gmail.com wrote:
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be
Hi!
In essence the example would be something along the lines of $s must be
a string with length exactly 4 and if not, trigger_error() with the
given error message and error level.
OK, I see what you mean, but it is still unclear what such construct
does. At least conceptually, I do not
85 matches
Mail list logo
