Hi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka. Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with
PHP karma.
The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.
This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have
ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.
Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different
meaning. Example: (Metaphor) I am all ears.
Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.
A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded inside
the service, so the solution would be an external factor that explains
to service how to validate the DO. One of the possible implementations
would be a UserValidator class that contains validation rules for each
field. This external factor is a good sample of meta-information. But
how would a meta attribute would solve this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:
class User {
<Email Meta Information>
protected $email;
<At least 6 chars Meta Information>
protected $password;
}
NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.
Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc. - Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc. - Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc. - FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.
Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?
Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I don't see a point in repeating the discussion we've already had on that topic several weeks ago. There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't.
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with PHP
karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well fit
together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We have
tokens (words), a syntax, semantic. But the lack of contextualization brings a
hole on language and how your application should behave. This behavior can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of someone
that is reading. He'd think person only have ears, but if you meta notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is time to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example, email
as an email and password with at least 6 chars. A generic validation service
could not have the User validation hardcoded inside the service, so the
solution would be an external factor that explains to service how to validate
the DO. One of the possible implementations would be a UserValidator class
that contains validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information> protected $password;}
NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe, visit:
http://www.php.net/unsub.php
hi,
The good reason is to actually understand what we are talking about.
And seeing phpdoc mentioned in almost all replies tell me that we
don't.
I don't see a point in repeating the discussion we've already had on that topic several weeks ago. There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't.
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with PHP
karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well fit
together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We have
tokens (words), a syntax, semantic. But the lack of contextualization brings a
hole on language and how your application should behave. This behavior can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of someone
that is reading. He'd think person only have ears, but if you meta notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is time to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example, email
as an email and password with at least 6 chars. A generic validation service
could not have the User validation hardcoded inside the service, so the
solution would be an external factor that explains to service how to validate
the DO. One of the possible implementations would be a UserValidator class
that contains validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information>
protected $password;
}NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe, visit:
http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Suggesting phpdoc is used for the purposes mentioned does not mean we don't understand what we're talking about.
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 12:43 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionhi,
The good reason is to actually understand what we are talking about.
And seeing phpdoc mentioned in almost all replies tell me that we don't.I don't see a point in repeating the discussion we've already had on that
topic several weeks ago. There needs to be an overwhelmingly good reason
to add a brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people
with PHP karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a
known information. Our sentence would mean that spoker person only
have ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different meaning.
Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded
inside the service, so the solution would be an external factor that
explains to service how to validate the DO. One of the possible
implementations would be a UserValidator class that contains
validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information>
protected $password;
}NOTE: Please understand that this do not enter in any
implementation details. It is not time (yet) to talk baout docblock, new
syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit
a language, I compiled a simple list of known projects and how can
they benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for
catching exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc.- Zend Framework Server classes Used to automate mappings for
XML-RPC, SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Suggesting phpdoc is used for the purposes mentioned does not mean we don't understand what we're talking about.
I feel like you never used annotations in other languages, did you?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I have certainly wanted them many times - especially when using SOAP.
Having WSDL auto-generation without compromising developer
documentation and attempting to have user-land code parse phpdoc for this
purpose seem{ed,s} counterintuitive. That said, introducing annotations is
a HUGE undertaking and would require a ton of work with potentially little
return. I do think it would be worth looking into in a future major
release, but there are quite a few other things that would be more
beneficial to the community for immediate discussions.
Did anyone write and RFC on this? guilhermeblanco has a good start.
Suggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
The patch is already written and a RFC created by Guilherme:
http://wiki.php.net/rfc/annotations .
I personally think annotations could make a great addition to PHP.
I agree with Will that annotations are especially useful for SOAP and
XML-RPC. I personally think annotations are useful for APIs in general.
Instead of creating a method to respond to a XML-RPC call, then binding
it to a specific XML-RPC call with a line in the initialization you
could just do this:
@xmlrpc({
name : "server.getValue",
params : {
param1 : {
type : "number",
docs : "This is documentation for param1"
}
}
});
public getValForXMLRPC ($param) {
...
I just used JSON for the syntax of annotation. I did this for two
reasons: 1. most PHP developers can write some Javascript, and 2. since
this is supposed to avoid syntax discussions, I used a syntax no one
uses for annotations, but everyone understands.
The possibilities are endless with Annotations and as long as they are
pretty speedy I think they would be picked up quite quickly and we would
get some great examples from the community.
My 2 cents.
-Alec
I have certainly wanted them many times - especially when using SOAP.
Having WSDL auto-generation without compromising developer
documentation and attempting to have user-land code parse phpdoc for this
purpose seem{ed,s} counterintuitive. That said, introducing annotations is
a HUGE undertaking and would require a ton of work with potentially little
return. I do think it would be worth looking into in a future major
release, but there are quite a few other things that would be more
beneficial to the community for immediate discussions.Did anyone write and RFC on this? guilhermeblanco has a good start.
Suggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Wow. I should actually look at the RFCs more frequently.
I have to say, assuming the patch is valid for PHP 5.3 (which I have no
doubt it is), I don't see why this can't be taken more seriously. I know
the discussion was brought up a few weeks ago, but what are the objections
to injecting this functionality into the next major post-5.4 release?
The patch is already written and a RFC created by Guilherme:
http://wiki.php.net/rfc/annotations .I personally think annotations could make a great addition to PHP.
I agree with Will that annotations are especially useful for SOAP and
XML-RPC. I personally think annotations are useful for APIs in general.Instead of creating a method to respond to a XML-RPC call, then binding it
to a specific XML-RPC call with a line in the initialization you could just
do this:@xmlrpc({
name : "server.getValue",
params : {
param1 : {
type : "number",
docs : "This is documentation for param1"
}
}
});
public getValForXMLRPC ($param) {
...I just used JSON for the syntax of annotation. I did this for two reasons:
- most PHP developers can write some Javascript, and 2. since this is
supposed to avoid syntax discussions, I used a syntax no one uses for
annotations, but everyone understands.The possibilities are endless with Annotations and as long as they are
pretty speedy I think they would be picked up quite quickly and we would get
some great examples from the community.My 2 cents.
-Alec
I have certainly wanted them many times - especially when using SOAP.
Having WSDL auto-generation without compromising developer
documentation and attempting to have user-land code parse phpdoc for this
purpose seem{ed,s} counterintuitive. That said, introducing annotations
is
a HUGE undertaking and would require a ton of work with potentially little
return. I do think it would be worth looking into in a future major
release, but there are quite a few other things that would be more
beneficial to the community for immediate discussions.Did anyone write and RFC on this? guilhermeblanco has a good start.
On Mon, Nov 15, 2010 at 5:44 PM, Pierre Joyepierre.php@gmail.com
wrote:Suggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.
I feel like you never used annotations in other languages, did you?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
Mostly it is that a new syntax will confuse people and add complexity
that PHP doesn't need. The same people don't believe that annotations
bring value worthy of adding a new syntax. Short array notation and
similar are noted as precedence.
That is a bulk of the arguments, but if I have forgotten any please
state them.
-Alec
Wow. I should actually look at the RFCs more frequently.
I have to say, assuming the patch is valid for PHP 5.3 (which I have no
doubt it is), I don't see why this can't be taken more seriously. I know
the discussion was brought up a few weeks ago, but what are the objections
to injecting this functionality into the next major post-5.4 release?The patch is already written and a RFC created by Guilherme:
http://wiki.php.net/rfc/annotations .I personally think annotations could make a great addition to PHP.
I agree with Will that annotations are especially useful for SOAP and
XML-RPC. I personally think annotations are useful for APIs in general.Instead of creating a method to respond to a XML-RPC call, then binding it
to a specific XML-RPC call with a line in the initialization you could just
do this:@xmlrpc({
name : "server.getValue",
params : {
param1 : {
type : "number",
docs : "This is documentation for param1"
}
}
});
public getValForXMLRPC ($param) {
...I just used JSON for the syntax of annotation. I did this for two reasons:
- most PHP developers can write some Javascript, and 2. since this is
supposed to avoid syntax discussions, I used a syntax no one uses for
annotations, but everyone understands.The possibilities are endless with Annotations and as long as they are
pretty speedy I think they would be picked up quite quickly and we would get
some great examples from the community.My 2 cents.
-Alec
I have certainly wanted them many times - especially when using SOAP.
Having WSDL auto-generation without compromising developer
documentation and attempting to have user-land code parse phpdoc for this
purpose seem{ed,s} counterintuitive. That said, introducing annotations
is
a HUGE undertaking and would require a ton of work with potentially little
return. I do think it would be worth looking into in a future major
release, but there are quite a few other things that would be more
beneficial to the community for immediate discussions.Did anyone write and RFC on this? guilhermeblanco has a good start.
On Mon, Nov 15, 2010 at 5:44 PM, Pierre Joyepierre.php@gmail.com
wrote:Suggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.
I feel like you never used annotations in other languages, did you?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
@Will: Patch works perfectly with PHP 5.3. There is just a minor issue
related to APC not caching instances.
That patch didn't reach a consensus and that's why I opened a
different thread to implement a patch based on poll results.
Cheers,
Wow. I should actually look at the RFCs more frequently.
I have to say, assuming the patch is valid for PHP 5.3 (which I have no
doubt it is), I don't see why this can't be taken more seriously. I know
the discussion was brought up a few weeks ago, but what are the objections
to injecting this functionality into the next major post-5.4 release?The patch is already written and a RFC created by Guilherme:
http://wiki.php.net/rfc/annotations .I personally think annotations could make a great addition to PHP.
I agree with Will that annotations are especially useful for SOAP and
XML-RPC. I personally think annotations are useful for APIs in general.Instead of creating a method to respond to a XML-RPC call, then binding it
to a specific XML-RPC call with a line in the initialization you could just
do this:@xmlrpc({
name : "server.getValue",
params : {
param1 : {
type : "number",
docs : "This is documentation for param1"
}
}
});
public getValForXMLRPC ($param) {
...I just used JSON for the syntax of annotation. I did this for two reasons:
- most PHP developers can write some Javascript, and 2. since this is
supposed to avoid syntax discussions, I used a syntax no one uses for
annotations, but everyone understands.The possibilities are endless with Annotations and as long as they are
pretty speedy I think they would be picked up quite quickly and we would get
some great examples from the community.My 2 cents.
-Alec
I have certainly wanted them many times - especially when using SOAP.
Having WSDL auto-generation without compromising developer
documentation and attempting to have user-land code parse phpdoc for this
purpose seem{ed,s} counterintuitive. That said, introducing annotations
is
a HUGE undertaking and would require a ton of work with potentially little
return. I do think it would be worth looking into in a future major
release, but there are quite a few other things that would be more
beneficial to the community for immediate discussions.Did anyone write and RFC on this? guilhermeblanco has a good start.
On Mon, Nov 15, 2010 at 5:44 PM, Pierre Joyepierre.php@gmail.com
wrote:On Tue, Nov 16, 2010 at 12:39 AM, Zeev Suraskizeev@zend.com wrote:
Suggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.
I feel like you never used annotations in other languages, did you?
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 1:45 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionSuggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
You got me... But as an intelligent human being I'd like to think I can evaluate the merits of a feature without having to actually use it.
I'm not saying that annotations don't give you any value. Sure they do. I'm saying that they come at a great price of adding an obscure branch of syntax into a language that's already grown significantly in complexity, and the bang for the buck isn't worth it. Those advanced developers needing that feature can make do with phpdoc.
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 1:45 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support
discussionSuggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
You got me... But as an intelligent human being I'd like to think I can
evaluate the merits of a feature without having to actually use it.I'm not saying that annotations don't give you any value. Sure they do.
I'm saying that they come at a great price of adding an obscure branch of
syntax into a language that's already grown significantly in complexity, and
the bang for the buck isn't worth it. Those advanced developers needing
that feature can make do with phpdoc.Zeev
--
it can't see your point.
if the current phpdoc would be enough, then they wouldn't propose the
annotation.
if you can't do everything with phpdoc that you could do with annotation,
then I can see 2 choice:
- forget the advanced stuff, but in this case, don try to sound as the
phpdoc would be an alternative - extend the phpdoc support to cover the missing parts: how would that less
obscure? phpdoc isn't up for the task.
if you did read the RFC and did your research about the annotations, then
you know that.
Tyrael
If past experience is any indicator then you’re hardly correct regarding your first statement – being able to do something in PHP was no insurance against proposals suggesting new ways of doing the same thing – often in an improved way.
Re: the 2nd part, extending phpdoc would be way less obscure because we’d be building on existing, already defined and widely used syntax. To make it clear – I’m not suggesting we add all of the complexity of the annotations proposal on top of phpdoc, but something fairly minimal. That’s why I said developers should ‘make do’ with phpdoc (with slight improvements around storing doc blocks where we don’t store them today).
Like I said – of course annotations bring value. If that was the only property when evaluating a new feature to be added, PHP would very quickly become an everything-and-the-kitchen-sink language. Thankfully, it’s not.
Zeev
it can't see your point.
if the current phpdoc would be enough, then they wouldn't propose the annotation.
if you can't do everything with phpdoc that you could do with annotation, then I can see 2 choice:
- forget the advanced stuff, but in this case, don try to sound as the phpdoc would be an alternative
- extend the phpdoc support to cover the missing parts: how would that less obscure? phpdoc isn't up for the task.
if you did read the RFC and did your research about the annotations, then you know that.
Tyrael
November-16-10 2:21 AM - Zeev Suraski wrote:
Like I said – of course annotations bring value. If that was the only
property when evaluating a new feature to be added, PHP would very
quickly become an everything-and-the-kitchen-sink language.
Thankfully, it’s not.
Amen.
-1
Best Regards
Mike Robinson
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 1:45 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionSuggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
You got me... But as an intelligent human being I'd like to think I can evaluate the merits of a feature without having to actually use it.
I'm not saying that annotations don't give you any value. Sure they do. I'm saying that they come at a great price of adding an obscure branch of syntax into a language that's already grown significantly in complexity, and the bang for the buck isn't worth it. Those advanced developers needing that feature can make do with phpdoc.
Zeev
Hi all.
I use PHPDoc. I develop SOAP services and use ZF to autocreate my WSDL
files. I've used tools to create classes from a WSDL file. I don't
know how this qualifies specifically as "annotations" - so I'm
probably in the same camp as Zeev on this.
An issue for me is the lack of ongoing development (it seems) of
phpdoc. Yes, sure, it is for documentation. But that is just one sort
of annotation. [1]
I think having a mechanism which is easily understood in both human
and machine terms and obeys a simple, expandable syntax, then this
would seem to be extremely useful.
I like the idea of JSON encoded annotations. JSON is very simple to
understand (if you can manually create a nested associative array in
PHP, you can create JSON encoded data).
I think for more complex annotations, a simple @tag doesn't seem like
it is going to be enough. There is no way to nest the tags in any
meaningful and validatable way. At least not in a way that is obvious
when you read it. Also, for every new @tag, you have to tell PHPDoc to
ignore it as it will produces noise.
But consider now the amount of PHPDoc blocks out there. A PHPDoc ->
annotations converter would have to be developed. Theoretically, one
SHOULD be able to do that using a PHPDoc template - I think - not an
area I know well.
One issue mentioned is that having annotations will have a
"performance hit" on PHP.
I'm obviously missing something here. If the annotation is in a
blockcomment, then that would seem to satisfy the performance issue.
Reading the annotation for normal runtime execution would seem wrong.
Only as part of reflection or annotation specific access should the
block be "decoded" into whatever form is required.
So, aren't annotations really just an extension to the docblock
decoding aspects of reflection? Do we have a "performance hit" because
of reflection?
I know I know very little about the impact on PHP, but a simple syntax
wrapped in a comment would really seem to be an ideal approach to me.
So much so, I'm almost surprised we need anything in the core at all.
Regards,
Richard.
[1] http://en.wikipedia.org/wiki/Annotation#Software_programming
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Hi Richard,
The first proposed patch has some performance impact, due to the
parsing time. And that's just it.
Instantiation of annotation classes is irrelevant because it only
happens when you explicitly request for it at runtime. The only
drawback is that it cannot be cached in APC.
Cheers,
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 1:45 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionSuggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
You got me... But as an intelligent human being I'd like to think I can evaluate the merits of a feature without having to actually use it.
I'm not saying that annotations don't give you any value. Sure they do. I'm saying that they come at a great price of adding an obscure branch of syntax into a language that's already grown significantly in complexity, and the bang for the buck isn't worth it. Those advanced developers needing that feature can make do with phpdoc.
Zeev
Hi all.
I use PHPDoc. I develop SOAP services and use ZF to autocreate my WSDL
files. I've used tools to create classes from a WSDL file. I don't
know how this qualifies specifically as "annotations" - so I'm
probably in the same camp as Zeev on this.An issue for me is the lack of ongoing development (it seems) of
phpdoc. Yes, sure, it is for documentation. But that is just one sort
of annotation. [1]I think having a mechanism which is easily understood in both human
and machine terms and obeys a simple, expandable syntax, then this
would seem to be extremely useful.I like the idea of JSON encoded annotations. JSON is very simple to
understand (if you can manually create a nested associative array in
PHP, you can create JSON encoded data).I think for more complex annotations, a simple @tag doesn't seem like
it is going to be enough. There is no way to nest the tags in any
meaningful and validatable way. At least not in a way that is obvious
when you read it. Also, for every new @tag, you have to tell PHPDoc to
ignore it as it will produces noise.But consider now the amount of PHPDoc blocks out there. A PHPDoc ->
annotations converter would have to be developed. Theoretically, one
SHOULD be able to do that using a PHPDoc template - I think - not an
area I know well.One issue mentioned is that having annotations will have a
"performance hit" on PHP.I'm obviously missing something here. If the annotation is in a
blockcomment, then that would seem to satisfy the performance issue.
Reading the annotation for normal runtime execution would seem wrong.
Only as part of reflection or annotation specific access should the
block be "decoded" into whatever form is required.So, aren't annotations really just an extension to the docblock
decoding aspects of reflection? Do we have a "performance hit" because
of reflection?I know I know very little about the impact on PHP, but a simple syntax
wrapped in a comment would really seem to be an ideal approach to me.
So much so, I'm almost surprised we need anything in the core at all.Regards,
Richard.
[1] http://en.wikipedia.org/wiki/Annotation#Software_programming
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 1:45 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support discussionSuggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
You got me... But as an intelligent human being I'd like to think I can
evaluate the merits of a feature without having to actually use it.I'm not saying that annotations don't give you any value. Sure they
do. I'm saying that they come at a great price of adding an obscure
branch of syntax into a language that's already grown significantly in
complexity, and the bang for the buck isn't worth it. Those advanced
developers needing that feature can make do with phpdoc.
I would have no trouble accepting a rejection of annotations on the actual
merits, but the interminable sequence of comparisons to phpdoc make it
clear to me that people just don't realize the potential of annotations.
First, can docblock comments substitute the current proposal of
annotations?
YES, they can. Leave everything the same in the current annotations
implementation and just tweak the grammar so that docblock comments are
parsed for annotations.
Of course, no one is actually proposing this, because at this point people
usually realize it would be crazy to do such a thing. So the "alternative"
they actually propose is a watered-down-to-nothing version of annotations,
put as "add an API to parse docblock comments". This homeopathic version
of annotations solves only a small subset of what you can actually do with
annotations, as I've explained in the past (see
http://news.php.net/php.internals/49674 ).
Yes, it is new syntax and by itself that is undesirable. However, I see
annotations has actually saving us from having to had new syntax for new
functionality in the future. The ability of using annotations to sort-of
extend a language is one thing that has actually mitigated the lack of new
language features in Java in the last few years.
Want to add support for AOP? We can use annotations to define joint
points, pointcuts and advice.
Define properties as non-null, having a certain type or being read-only?
We can use annotations instead of adding new keywords.
More general forms of design by contract?
Etc etc.
It must be said at this point that annotations are not perfect. Too many
annotations can make the code unreadable and they can make the program
flow non-obvious. Despite their versatility, they still have a relatively
rigid structure. A more interesting option would be to allow either
extensions or scripts to extend the grammar to better reflect the domain
of the application (this could then also be used to implemented
annotations). However, I think that, at this point, adding annotations
directly to the language would be a fair trade-off.
--
Gustavo Lopes
Hi!
I would have no trouble accepting a rejection of annotations on the actual
merits, but the interminable sequence of comparisons to phpdoc make it
clear to me that people just don't realize the potential of annotations.
People do realize the potential, what you and many "+1" voters seem to
not realize is the cost. You propose to add new syntax into PHP which is
completely different from all other syntax constructs in PHP - different
instantiation syntax, different method parameters syntax.
It's a full micro-language inside PHP. We discussed it already, but
somehow it failed to register.
Yes, it is new syntax and by itself that is undesirable. However, I see
The problem is not new syntax per se. The problem is new syntax for
things that already have old syntax.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Wed, 17 Nov 2010 01:54:22 -0000, Stas Malyshev smalyshev@sugarcrm.com
wrote:
The problem is not new syntax per se. The problem is new syntax for
things that already have old syntax.
This is incontestably false. Although a big portion of the use cases can
awkwardly use the user-space parsed and interpreted docblocks, I'm more
interested in the potential for applications that require the engine to
parse to annotations (like in the patch, not doing it on demand for
bocblocks) and, for a select few, act upon them.
Your preoccupation with the cost of adding new syntax is reasonable and
the patch goes too far, but surely we could iron out those details later.
Maybe even just preceding the class/method/whatever declaration with an
annotation expressed with normal object instantiation syntax?...
--
Gustavo Lopes
Hi Gustavo,
Normal instantiation cannot be done.
Here is a sample where it would fail:
new Foo()
class User { ... }
So it must be something different.
[]s,
On Wed, 17 Nov 2010 01:54:22 -0000, Stas Malyshev smalyshev@sugarcrm.com
wrote:The problem is not new syntax per se. The problem is new syntax for things
that already have old syntax.This is incontestably false. Although a big portion of the use cases can
awkwardly use the user-space parsed and interpreted docblocks, I'm more
interested in the potential for applications that require the engine to
parse to annotations (like in the patch, not doing it on demand for
bocblocks) and, for a select few, act upon them.Your preoccupation with the cost of adding new syntax is reasonable and the
patch goes too far, but surely we could iron out those details later. Maybe
even just preceding the class/method/whatever declaration with an annotation
expressed with normal object instantiation syntax?...--
Gustavo Lopes--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi!
I would have no trouble accepting a rejection of annotations on the actual
merits, but the interminable sequence of comparisons to phpdoc make it
clear to me that people just don't realize the potential of annotations.People do realize the potential, what you and many "+1" voters seem to not
realize is the cost. You propose to add new syntax into PHP which is
completely different from all other syntax constructs in PHP - different
instantiation syntax, different method parameters syntax.
It's a full micro-language inside PHP. We discussed it already, but somehow
it failed to register.Yes, it is new syntax and by itself that is undesirable. However, I see
The problem is not new syntax per se. The problem is new syntax for things
that already have old syntax.
I'm a +1 in terms of PHP having support for meta data.
The issues that seem to be raised so far are:
1 - New syntax / micro-language / etc to learn
2 - Parser performance and new parser to code/develop/test
3 - APC cacheing of meta data.
What if the meta data is just more PHP code? We all know PHP. The
parser already works. APC already gets it op-codes. Nothing
significantly new to learn/develop/test.
With DocBlocks, the comments are relative to the element they are
describing and are placed immediately before the item in question,
with the exception of a file level docblock.
Keeping with that, what if there was 1 new keyword; something like
annotate or annotation.
This keyword would operate in the same was as class.
I don't know what the content of the annotation would be, but if I was
asked to try and describe what an annotation looks like, based upon
what I've seen, it looks like a set of consts. The items don't change,
just like a const. Please bear in mind that I've not used annotations
beyond docblocks and wsdl generation.
So, maybe something like this ...
<?php
annotate FILE {
const Author = "Richard Quadling";
const Category = "Richard's Framework";
const Copyright = "Copyright (c) 2005-2010 Richard Quadling"
const Package = "Win32";
const Subpackage = "Service";
const Version = 1.0;
}
annotate Win32_Service {
const Title = "Win32_Service";
const Description = "This abstract class allows for the installation,
uninstallation and execution of a PHP script as a Microsoft Windows
Service.";
const Abstract = True;
const Package = "Win32";
const Subpackage = "Service";
const Version = "$Id: Service.php,v 1.0.53 2010-11-15T12:49:48+00:00
RichardQ $";
}
abstract class Win32_Service extends Task {
....
}
?>
From this, I think there would need to be a few changes.
1 - "annotate" may not be enough, so maybe annotateFile,
annotateClass, annotateFunction, annotateXxxxx, where xxxx is the
element type being annotated - possibly/probably too much.
2 - Because some of suggestions on what annotations need to support
includes nested data, a const would need to be allow for an array to
be assigned. Personally, I think supporting a const array is a pretty
useful idea.
The advantages that I see here are hopefully fairly obvious.
1 - No new significant core changes. Essentially a new type of class.
If annotateFile is the preferred route, then this obeys the rules like
namespaces. Only 1 per file. As would annotateNamespace.
2 - The syntax is extremely familiar.
3 - There is nothing significantly new in the parser (naive assumption).
4 - APC would get the data in the same way as if it was a class or a namespace.
5 - Adding new elements to the annotation would involve absolutely no
changes to core. You want to add meta data describing the COBOL
picture format of a parameter or the regex validation rule that will
be used, then fine. Nothing in the engine will change.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Hello Internals!
For me, as a user-land developer, this issue seems as if some people
are trying to push the annotations at any cost. What they fail to see,
is that annotations are never described what they are and how they can
be useful in our developer work. Right now I, and I think many other
user-land developers, just fail to see what the annotations are
without any meaningful example.
Right now I stand for ditching the annotations and schedule to return
to them later, after 5.4 or whatever it will be.
Right now there are more pressing things to deal with in PHP:
- PDO is stuck in its development and mysqli & co are quite better developed.
- tainted variables are a huge bonus but somehow they are stuck in the
draft mode too (http://wiki.php.net/rfc/taint - hell, I wait for this
getting into the PHP for a loooooooooooong time and there are patches) - Traits are mostly discussed and probably need finishing touches.
And these have a clear and understood benefit of being worked upon.
Annotations now are just a big WTF. The fact that only a handful of
developers reply to this thread (remember the type hinting thread -
there where tons of reply's from many people) just shows that we as a
com unity are not ready for annotations. Most of us just don't know
that this is and how it's supposed to be used,
Really, there is a ton of work to finish what is already has been
started and needs attention. Type hints had the same story as
annotations now. No easy agreement - ditched the discussion till next
major version.
On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks
arvids.godjuks@gmail.comwrote:
Hello Internals!
For me, as a user-land developer, this issue seems as if some people
are trying to push the annotations at any cost. What they fail to see,
is that annotations are never described what they are and how they can
be useful in our developer work. Right now I, and I think many other
user-land developers, just fail to see what the annotations are
without any meaningful example.Right now I stand for ditching the annotations and schedule to return
to them later, after 5.4 or whatever it will be.
Right now there are more pressing things to deal with in PHP:
- PDO is stuck in its development and mysqli & co are quite better
developed.- tainted variables are a huge bonus but somehow they are stuck in the
draft mode too (http://wiki.php.net/rfc/taint - hell, I wait for this
getting into the PHP for a loooooooooooong time and there are patches)- Traits are mostly discussed and probably need finishing touches.
And these have a clear and understood benefit of being worked upon.
Annotations now are just a big WTF. The fact that only a handful of
developers reply to this thread (remember the type hinting thread -
there where tons of reply's from many people) just shows that we as a
com unity are not ready for annotations. Most of us just don't know
that this is and how it's supposed to be used,Really, there is a ton of work to finish what is already has been
started and needs attention. Type hints had the same story as
annotations now. No easy agreement - ditched the discussion till next
major version.--
I agree with you; there are more important issues than some "syntactic
sugar", for example Large File Support, unicode support, pdo, pecl4win,
optimizating the error handling (generating full backtrace and such for
every error, which are just gets discarded/ignored, etc.), upload progress
(I think APC provides this.), to name just a few from the top of my head.
the only problem is, that they either hard, or boring to implement, or there
isn't any agreement on them.
my point is with this is that maybe there are more important features for
you, or for me, but if nobody can/want working on those issues, why should
we reject an improvement, which has actiove supporters? (they did write an
RFC and patch, and they brought the issue to the list, so everybody can tell
their opinion/concerns, and help to chose the best possible solution).
So as long as the above mentioned problems are unsolved, we could reject
every other improvement/addition, because there are more important, or older
problems to solve.
But I wont go to that direction, would you?
Tyrael
On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks <arvids.godjuks@gmail.com
wrote:
Hello Internals!
For me, as a user-land developer, this issue seems as if some people
are trying to push the annotations at any cost. What they fail to see,
is that annotations are never described what they are and how they can
be useful in our developer work. Right now I, and I think many other
user-land developers, just fail to see what the annotations are
without any meaningful example.Right now I stand for ditching the annotations and schedule to return
to them later, after 5.4 or whatever it will be.
Right now there are more pressing things to deal with in PHP:
- PDO is stuck in its development and mysqli & co are quite better
developed.- tainted variables are a huge bonus but somehow they are stuck in the
draft mode too (http://wiki.php.net/rfc/taint - hell, I wait for this
getting into the PHP for a loooooooooooong time and there are patches)- Traits are mostly discussed and probably need finishing touches.
And these have a clear and understood benefit of being worked upon.
Annotations now are just a big WTF. The fact that only a handful of
developers reply to this thread (remember the type hinting thread -
there where tons of reply's from many people) just shows that we as a
com unity are not ready for annotations. Most of us just don't know
that this is and how it's supposed to be used,Really, there is a ton of work to finish what is already has been
started and needs attention. Type hints had the same story as
annotations now. No easy agreement - ditched the discussion till next
major version.--
I agree with you; there are more important issues than some "syntactic
sugar", for example Large File Support, unicode support, pdo, pecl4win,
optimizating the error handling (generating full backtrace and such for
every error, which are just gets discarded/ignored, etc.), upload progress
(I think APC provides this.), to name just a few from the top of my head.
the only problem is, that they either hard, or boring to implement, or
there isn't any agreement on them.my point is with this is that maybe there are more important features for
you, or for me, but if nobody can/want working on those issues, why should
we reject an improvement, which has actiove supporters? (they did write an
RFC and patch, and they brought the issue to the list, so everybody can tell
their opinion/concerns, and help to chose the best possible solution).So as long as the above mentioned problems are unsolved, we could reject
every other improvement/addition, because there are more important, or older
problems to solve.
But I wont go to that direction, would you?
On the other hand: it seems that more examples about the usage wouldn't hurt
in the RFC...
Tyrael
On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks
<arvids.godjuks@gmail.comwrote:
Hello Internals!For me, as a user-land developer, this issue seems as if some people
are trying to push the annotations at any cost. What they fail to see,
is that annotations are never described what they are and how they can
be useful in our developer work. Right now I, and I think many other
user-land developers, just fail to see what the annotations are
without any meaningful example.
snip
On the other hand: it seems that more examples about the usage wouldn't
hurt in the RFC...Tyrael
I have to agree with this sentiment in particular. As I've not worked in a
language with formal annotations, I still don't grok the use case.
To those supporting some form of syntactic annotations (whatever the syntax),
can you please explain, simply and preferably with examples, what I could do
with such syntax that I cannot do now in user-space, and/or what I could do
better/faster/cheaper with such tools than what I can do now in user-space?
I think that's the missing piece here: The practical ever-day example of how
my code would get better because of annotations.
--Larry Garfield
Hi Larry,
For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:
http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations
http://docs.symfony-reloaded.org/guides/validator.html
Please understand that Roman, Benjamin, Jonathan and I wrote this
Annotation parser for Doctrine, which was reused by Bernhard on
Symfony.
So I have clean understanding of the issue we have on hands and every
single point that it is required to address. That's why I wrote the
RFC.
Yesterday night a couple of people joined on #php.pecl and discussed a
possible new implementation.
I'll write what was discussed and probably some sample code.
Cheers,
On Wed, Nov 17, 2010 at 11:58 AM, Arvids Godjuks
<arvids.godjuks@gmail.comwrote:
Hello Internals!For me, as a user-land developer, this issue seems as if some people
are trying to push the annotations at any cost. What they fail to see,
is that annotations are never described what they are and how they can
be useful in our developer work. Right now I, and I think many other
user-land developers, just fail to see what the annotations are
without any meaningful example.snip
On the other hand: it seems that more examples about the usage wouldn't
hurt in the RFC...Tyrael
I have to agree with this sentiment in particular. As I've not worked in a
language with formal annotations, I still don't grok the use case.To those supporting some form of syntactic annotations (whatever the syntax),
can you please explain, simply and preferably with examples, what I could do
with such syntax that I cannot do now in user-space, and/or what I could do
better/faster/cheaper with such tools than what I can do now in user-space?I think that's the missing piece here: The practical ever-day example of how
my code would get better because of annotations.--Larry Garfield
--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi Larry,
For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-
mapping/en#introduction-to-docblock-annotations
http://docs.symfony-reloaded.org/guides/validator.htmlPlease understand that Roman, Benjamin, Jonathan and I wrote this
Annotation parser for Doctrine, which was reused by Bernhard on
Symfony.
So I have clean understanding of the issue we have on hands and every
single point that it is required to address. That's why I wrote the
RFC.
I'm really confused about the "issue", no objections have been made for a docblock parser for "annotations".
That can easily live as PECL extension, Doctrine ORM mapping can done in XML, YAML, docblock annotations,... symphony validation in XML, YAML, docblock annotations, ...?
Why is it such a persistent issue to have language level annotations?
Because people want their decorative data around class properties? Java developers who want their hibernate?
For uses cases in java (annotations as hints to the compiler):
http://video.google.com/videoplay?docid=-1531727105949862857#
Does this even apply to php? Hints to the parser? Optimizations?
I'll say it again, I'm not against annotations but copying java and its mistakes is not the way to go. Remember that vendors (oracle, bea,...) love annotations to sell their tools, in orm hibernate won.
Please improve the RFC to address php-specific problems
Now, I'm going to go back and listen to that song "sugar, sugar" by the archies
Hi Larry,
For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations
http://docs.symfony-reloaded.org/guides/validator.htmlPlease understand that Roman, Benjamin, Jonathan and I wrote this
Annotation parser for Doctrine, which was reused by Bernhard on
Symfony.
So I have clean understanding of the issue we have on hands and every
single point that it is required to address. That's why I wrote the
RFC.Yesterday night a couple of people joined on #php.pecl and discussed a
possible new implementation.
I'll write what was discussed and probably some sample code.
No offense, but as I've noted before Symfony and Doctrine are very very
different types of frameworks/libraries than a lot of the code out
there. Much of what may make sense in a component framework doesn't
make sense in a full stack framework (e.g., Drupal, which I work on) and
vice versa. So while I respect that you put a lot of work into the
Doctrine and Symfony implementations that does not mean you will
understand "every single point that it is required to address".
That said, from looking at the Symfony page above it looks like it's an
integrated system for providing variable-level validation. True?
If that's the case, what would a before/after look like for code using
annotations vs. not?
As far as implementation goes, for something like this to be useful for
a highly-dynamic system like Drupal we'd need to be able to add
annotations/validation rules out-of-band, that is, from somewhere other
than syntactically right on the variable/function/method being
validated. We frequently have highly-generic objects that get used in a
multitude of different ways, so we would need to be able to associate
validation rules at runtime for them to work.
Naturally the error messages from them would also need to be
returned/thrown, not printed, so an application can take proper steps
with them in its own error handling routines.
--Larry Garfield
Hi Larry,
Of course I know how it can benefit a full stack framework.
For example Zend Framework can benefit of it by auto-generating WSDL
files in Zend_Soap.
You're right about Symfony integrated system of property validation of
Domain Objects.
If you would like to see how it would be implemented in
Doctrine/Symfony without Annotations, here are the links of them:
Doctrine sample user class:
https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php
Symfony injection of property validation:
http://docs.symfony-reloaded.org/guides/validator.html (at the end of
HTML file)
Cheers,
On Thu, Nov 18, 2010 at 3:00 PM, larry@garfieldtech.com
larry@garfieldtech.com wrote:
Hi Larry,
For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations
http://docs.symfony-reloaded.org/guides/validator.htmlPlease understand that Roman, Benjamin, Jonathan and I wrote this
Annotation parser for Doctrine, which was reused by Bernhard on
Symfony.
So I have clean understanding of the issue we have on hands and every
single point that it is required to address. That's why I wrote the
RFC.Yesterday night a couple of people joined on #php.pecl and discussed a
possible new implementation.
I'll write what was discussed and probably some sample code.No offense, but as I've noted before Symfony and Doctrine are very very
different types of frameworks/libraries than a lot of the code out there.
Much of what may make sense in a component framework doesn't make sense in
a full stack framework (e.g., Drupal, which I work on) and vice versa. So
while I respect that you put a lot of work into the Doctrine and Symfony
implementations that does not mean you will understand "every single point
that it is required to address".That said, from looking at the Symfony page above it looks like it's an
integrated system for providing variable-level validation. True?If that's the case, what would a before/after look like for code using
annotations vs. not?As far as implementation goes, for something like this to be useful for a
highly-dynamic system like Drupal we'd need to be able to add
annotations/validation rules out-of-band, that is, from somewhere other than
syntactically right on the variable/function/method being validated. We
frequently have highly-generic objects that get used in a multitude of
different ways, so we would need to be able to associate validation rules at
runtime for them to work.Naturally the error messages from them would also need to be
returned/thrown, not printed, so an application can take proper steps with
them in its own error handling routines.--Larry Garfield
--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
But, in my opinion at least, parsing docblocks also brings in a new
syntax. The only difference that I see is that parsing docblocks is
wrapped in a comment and not syntax highlighted by most editors.
Just out of curiosity, how did traits make it into 5.4 if we are
avoiding syntax changes? You could use the same argument for traits:
they introduce new syntax and advanced users can make do by copying and
pasting. You could make the same argument for many features.
You seem to have a issue with introducing new syntax. How would you feel
if the syntax was very similar? Would you say that the "price" of this
feature would be much lower and possibly even worth it. Maybe the syntax
would look something like this:
attribute RestMethod('/do/something', 'Do Stuff', 'Does something.', array(
'arg1' => 'A cool argument!'
));
public static DoSomething($arg1) {
...
or
attribute Example('arg', 'arg2', 3, (time() > 0 ? true : false));
class Demo {
...
That way it is clear that that line is an attribute. If the person
doesn't know what an "attribute in PHP" is, they can Google it.
This does the following:
-
No new branch of syntax is introduced like C# style annotations or
parsed docblocks would. The syntax is very similar to standard PHP (the
only thing missing is the "new" before the class name, and the only new
thing is the word "attribute") -
This doesn't add significant complexity. It essentially makes
attributes autocalled class constructors. (As a side note, I don't think
any part of PHP is significantly complex, it just isn't
consistent--making it seem complex). -
It is quite clear that that line is an attribute. People will be able
to easily Google, find and read the PHP docs for an explanation.
I know we aren't supposed to go into syntax, but I am curious as to
people's reactions if things stay very "php-esque" instead of trying to
create a new syntax/imitate another language.
Also, don't get me wrong, I think parsable docblocks is a great idea and
I support it--just not for annotations.
-Alec
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 16, 2010 1:45 AM
To: Zeev Suraski
Cc: guilhermeblanco@gmail.com; PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionSuggesting phpdoc is used for the purposes mentioned does not mean we
don't understand what we're talking about.I feel like you never used annotations in other languages, did you?
You got me... But as an intelligent human being I'd like to think I can evaluate the merits of a feature without having to actually use it.
I'm not saying that annotations don't give you any value. Sure they do. I'm saying that they come at a great price of adding an obscure branch of syntax into a language that's already grown significantly in complexity, and the bang for the buck isn't worth it. Those advanced developers needing that feature can make do with phpdoc.
Zeev
[snip]
attribute RestMethod('/do/something', 'Do Stuff', 'Does something.',
array(
'arg1' => 'A cool argument!'
));
public static DoSomething($arg1) {
...or
attribute Example('arg', 'arg2', 3, (time() > 0 ? true : false));
class Demo {
...That way it is clear that that line is an attribute. If the person
doesn't know what an "attribute in PHP" is, they can Google it.This does the following:
No new branch of syntax is introduced like C# style annotations or
parsed docblocks would. The syntax is very similar to standard PHP
(the only thing missing is the "new" before the class name, and the
only new thing is the word "attribute")This doesn't add significant complexity. It essentially makes
attributes autocalled class constructors. (As a side note, I don't
think any part of PHP is significantly complex, it just isn't
consistent--making it seem complex).It is quite clear that that line is an attribute. People will be
able to easily Google, find and read the PHP docs for an explanation.
As a karma-less user, I actually quite like this syntax and it feels
very PHP-like to me. Making it trivially easy for people to search for
the explanation of a feature is an excellent idea.
Dave
@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.
If result of the poll says "OK" to meta attribute, then we can discuss
next topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of revamp another discussion that lead to nothing.
BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on that topic several weeks ago. There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't.
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with PHP
karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well fit
together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We have
tokens (words), a syntax, semantic. But the lack of contextualization brings a
hole on language and how your application should behave. This behavior can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of someone
that is reading. He'd think person only have ears, but if you meta notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is time to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example, email
as an email and password with at least 6 chars. A generic validation service
could not have the User validation hardcoded inside the service, so the
solution would be an external factor that explains to service how to validate
the DO. One of the possible implementations would be a UserValidator class
that contains validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information>
protected $password;
}NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe, visit:
http://www.php.net/unsub.php
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I forgot my vote too: +1
@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss
next topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on that topic several weeks ago. There needs to be an overwhelmingly good reason to add a brand new syntax to the language, a whole branch of it in the case of annotations - and there simply isn't.
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with PHP
karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well fit
together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We have
tokens (words), a syntax, semantic. But the lack of contextualization brings a
hole on language and how your application should behave. This behavior can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of someone
that is reading. He'd think person only have ears, but if you meta notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is time to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example, email
as an email and password with at least 6 chars. A generic validation service
could not have the User validation hardcoded inside the service, so the
solution would be an external factor that explains to service how to validate
the DO. One of the possible implementations would be a UserValidator class
that contains validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information> protected $password;}
NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe, visit:
http://www.php.net/unsub.php
+1 here.
I'd love to see the conversation of implementation.
I forgot my vote too: +1
@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss
next topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on that
topic several weeks ago. There needs to be an overwhelmingly good reason to
add a brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with
PHP
karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and
context.
We cannot define it as a language if we don't have these 4 parts well
fit
together.
For a simple sentence like: I am all ears, we can easily identify these
parts.
But the real meaning of this sentence (context) is only achieved with
another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We have
tokens (words), a syntax, semantic. But the lack of contextualization
brings a
hole on language and how your application should behave. This behavior
can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of
someone
that is reading. He'd think person only have ears, but if you meta
notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is time
to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
as an email and password with at least 6 chars. A generic validation
service
could not have the User validation hardcoded inside the service, so the
solution would be an external factor that explains to service how to
validate
the DO. One of the possible implementations would be a UserValidator
class
that contains validation rules for each field. This external factor is a
good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information> protected $password;}
NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
+1
On 15 November 2010 21:27, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss
next topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on that
topic several weeks ago. There needs to be an overwhelmingly good reason to
add a brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with
PHP
karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and
context.
We cannot define it as a language if we don't have these 4 parts well
fit
together.
For a simple sentence like: I am all ears, we can easily identify these
parts.
But the real meaning of this sentence (context) is only achieved with
another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We have
tokens (words), a syntax, semantic. But the lack of contextualization
brings a
hole on language and how your application should behave. This behavior
can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of
someone
that is reading. He'd think person only have ears, but if you meta
notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is time
to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
as an email and password with at least 6 chars. A generic validation
service
could not have the User validation hardcoded inside the service, so the
solution would be an external factor that explains to service how to
validate
the DO. One of the possible implementations would be a UserValidator
class
that contains validation rules for each field. This external factor is a
good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information> protected $password;}
NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity, @OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
In conjunction to my vote, I really think Pierrick's proposal and patch is
worth another look if we talk implementation.
On Mon, Nov 15, 2010 at 8:43 PM, Pierrick Charron pierrick@webstart.frwrote:
+1
On 15 November 2010 21:27, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss
next topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on
that
topic several weeks ago. There needs to be an overwhelmingly good reason
to
add a brand new syntax to the language, a whole branch of it in the case
of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with
PHP
karma.The first topic to be defined is: Does PHP need meta attribute
support?Any language is built at the top of syntax, words, semantics and
context.
We cannot define it as a language if we don't have these 4 parts well
fit
together.
For a simple sentence like: I am all ears, we can easily identify
these
parts.
But the real meaning of this sentence (context) is only achieved with
another
part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive
perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our
sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have
ears,
while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have
tokens (words), a syntax, semantic. But the lack of contextualization
brings a
hole on language and how your application should behave. This behavior
can
be achieved by many different ways; the simplest way is known as meta
information.Considering you have a lack of idiomatic expressions knowledge of
someone
that is reading. He'd think person only have ears, but if you meta
notify him
that it is a metaphor, he'd try to find a different meaning. Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is
time
to
understand how meta-information can benefit a computer language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
as an email and password with at least 6 chars. A generic validation
service
could not have the User validation hardcoded inside the service, so
the
solution would be an external factor that explains to service how to
validate
the DO. One of the possible implementations would be a UserValidator
class
that contains validation rules for each field. This external factor is
a
good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the
class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation
rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information> protected $password;}
NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne,
@Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
2010/11/16 Pierrick Charron pierrick@webstart.fr:
+1
+1 for annotations in 5.4
--
regards,
Kalle Sommer Nielsen
kalle@php.net
I hope I won't stir the pot too much, but with all due respect to the vote of at-best a two digit subset of an arbitrary 3000+ subscribers to internals, there's an overwhelming majority amongst the principal developers of PHP that voiced an opinion against it. While we have no official rules or structures for voting features into PHP, PHP being a meritocracy, that should be enough to put this RFC to bed.
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Tuesday, November 16, 2010 4:28 AM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussion@Zeev: That topic was related to an already built patch, which some where in
favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As soon as
we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss next
topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes instead of
revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on that
topic several weeks ago. There needs to be an overwhelmingly good reason
to add a brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people
with PHP karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a
known information. Our sentence would mean that spoker person only
have ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different meaning.
Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded
inside the service, so the solution would be an external factor that
explains to service how to validate the DO. One of the possible
implementations would be a UserValidator class that contains
validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information>
protected $password;
}NOTE: Please understand that this do not enter in any
implementation details. It is not time (yet) to talk baout docblock, new
syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit
a language, I compiled a simple list of known projects and how can
they benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for
catching exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc.- Zend Framework Server classes Used to automate mappings for
XML-RPC, SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
( Try again Zeev changing the pigging address ;) )
Zeev Suraski wrote:
I hope I won't stir the pot too much, but with all due respect to the vote of at-best a two digit subset of an arbitrary 3000+ subscribers to internals, there's an overwhelming majority amongst the principal developers of PHP that voiced an opinion against it. While we have no official rules or structures for voting features into PHP, PHP being a meritocracy, that should be enough to put this RFC to bed.
I'd second that.
There have been a number of developments added to PHP5 in the last few major
versions that offer little but irritation to main stream users. phpdoc is used
extensively for documentation, and it would be nice to see THAT fully supporting
these other tangents rather than simply inventing a new way of doing the same
thing. Lets please finish what we currently have work rather than adding yet
another layer of complexity.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi Lester,
If you READ my first email of this thread, you'll find out I do not
speak about new syntax, etc.
No matter if you say "that can be done through docblock", you're
automatically saying +1 to this thread.
Please re-read the topic and vote. Thanks.
Cheers,
( Try again Zeev changing the pigging address ;) )
Zeev Suraski wrote:I hope I won't stir the pot too much, but with all due respect to the vote
of at-best a two digit subset of an arbitrary 3000+ subscribers to
internals, there's an overwhelming majority amongst the principal developers
of PHP that voiced an opinion against it. While we have no official rules
or structures for voting features into PHP, PHP being a meritocracy, that
should be enough to put this RFC to bed.I'd second that.
There have been a number of developments added to PHP5 in the last few major
versions that offer little but irritation to main stream users. phpdoc is
used extensively for documentation, and it would be nice to see THAT fully
supporting these other tangents rather than simply inventing a new way of
doing the same thing. Lets please finish what we currently have work rather
than adding yet another layer of complexity.--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
guilhermeblanco@gmail.com wrote:
Hi Lester,
If you READ my first email of this thread, you'll find out I do not
speak about new syntax, etc.No matter if you say "that can be done through docblock", you're
automatically saying +1 to this thread.Please re-read the topic and vote. Thanks.
Does PHP need 'Meta attribute (aka. Annotations)' NO as it is yet another
addition when plenty of the existing ones have never been completed. How about
fixing PDO and other PHP5.1 features first? What is currently available does at
least work ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Your answer should have been just that. The overwhelming majority amongst
the principal developers of PHP voiced an opinion against it. I can
certainly understand the need for a meritocracy in PHP's current state. The
benefit of annotations for the masses vs performance hit and complexity
isn't currently worth it.
Saying developers needing annotations for specific functionality (e.g. SOAP)
should make do with phpdoc sends a bad message.
I hope I won't stir the pot too much, but with all due respect to the vote
of at-best a two digit subset of an arbitrary 3000+ subscribers to
internals, there's an overwhelming majority amongst the principal developers
of PHP that voiced an opinion against it. While we have no official rules
or structures for voting features into PHP, PHP being a meritocracy, that
should be enough to put this RFC to bed.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Tuesday, November 16, 2010 4:28 AM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support
discussion@Zeev: That topic was related to an already built patch, which some where
in
favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As soon
as
we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss
next
topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes
instead of
revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on
that
topic several weeks ago. There needs to be an overwhelmingly good reason
to add a brand new syntax to the language, a whole branch of it in the
case of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people
with PHP karma.The first topic to be defined is: Does PHP need meta attribute
support?Any language is built at the top of syntax, words, semantics and
context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify
these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a
known information. Our sentence would mean that spoker person only
have ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different
meaning.
Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded
inside the service, so the solution would be an external factor that
explains to service how to validate the DO. One of the possible
implementations would be a UserValidator class that contains
validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information> protected $password;}
NOTE: Please understand that this do not enter in any
implementation details. It is not time (yet) to talk baout docblock,
new
syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit
a language, I compiled a simple list of known projects and how can
they benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for
catching exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc.- Zend Framework Server classes Used to automate mappings for
XML-RPC, SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
Hi Zeev,
I hope I won't stir the pot too much, but with all due respect to the vote of at-best a two digit subset of an arbitrary 3000+ subscribers to internals, there's an overwhelming majority amongst the principal developers of PHP that voiced an opinion against it. While we have no official rules or structures for voting features into PHP, PHP being a meritocracy, that should be enough to put this RFC to bed.
Thanks for the input, but that's what I want to see in a democratic way.
YOU closed the previous thread, saying that "PHP does not need Annotations.".
Ok, I may have did something wrong previously, adding new syntax, etc.
So I decided to make it more democratic, and identify what can be done
in this subject.
If you READ what I wrote in the first email of this thread, you may
find that I do not add any implementation details. I'm just asking if
you agree into more discussion on this topic - on how can it be
implemented, syntax, where, etc -, or drop the entire idea completely.
So I'd second the same thing I did previously...
Let's listen to what people want. I already restricted the counting of
votes to people with PHP karma, so meritocracy is perfectly being
counted here.
Please stick to your vote and let other people vote. Do not close this
thread, again.
Cheers,
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Tuesday, November 16, 2010 4:28 AM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussion@Zeev: That topic was related to an already built patch, which some where in
favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As soon as
we reach some reasonable consensus, we can start another patch
implementation based on what we end up with this thread.If result of the poll says "OK" to meta attribute, then we can discuss next
topic (possible implementations).
Until then, I'd rather appreciate everyone to stick to their votes instead of
revamp another discussion that lead to nothing.BTW, I forgot to add my vote:
+1
I don't see a point in repeating the discussion we've already had on that
topic several weeks ago. There needs to be an overwhelmingly good reason
to add a brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, November 15, 2010 7:08 PM
To: PHP internals
Subject: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations)
support discussionHi folks,
I'll start a series of topics (in this thread) about meta attribute (aka.
Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be
discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people
with PHP karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a
known information. Our sentence would mean that spoker person only
have ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different meaning.
Example:
(Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded
inside the service, so the solution would be an external factor that
explains to service how to validate the DO. One of the possible
implementations would be a UserValidator class that contains
validation rules for each field. This external factor is a good
sample of meta-information. But how would a meta attribute would solve
this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information>
protected $password;
}NOTE: Please understand that this do not enter in any
implementation details. It is not time (yet) to talk baout docblock, new
syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit
a language, I compiled a simple list of known projects and how can
they benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for
catching exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc.- Zend Framework Server classes Used to automate mappings for
XML-RPC, SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On 15 November 2010 17:07, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka. Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic, so we can do some democratic
internals decision. I'd reduce the scope of voters to only people with
PHP karma.The first topic to be defined is: Does PHP need meta attribute support?
Any language is built at the top of syntax, words, semantics and context.
We cannot define it as a language if we don't have these 4 parts well
fit together.
For a simple sentence like: I am all ears, we can easily identify these parts.
But the real meaning of this sentence (context) is only achieved with
another part of the language: signifier-significate.
A signifier is an atomic form, material element, visible, sensitive.
A significate is an idea, semantic content, conceptual element, not
sensitive perceptive.This important part is only reminded when we get back to semantics,
specifically when talking about idiomatic expressions, a metaphor in
our sample. The meaning will only work if we have the context, a known
information. Our sentence would mean that spoker person only have
ears, while the true meaning is that he/she is paying attention.
A computer language doesn't differ from a language by any means. We
have tokens (words), a syntax, semantic. But the lack of
contextualization brings a hole on language and how your application
should behave. This behavior can be achieved by many different ways;
the simplest way is known as meta information.Considering you have a lack of idiomatic expressions knowledge of
someone that is reading. He'd think person only have ears, but if you
meta notify him that it is a metaphor, he'd try to find a different
meaning. Example: (Metaphor) I am all ears.Now that we find how meta-information can benefit languages, it is
time to understand how meta-information can benefit a computer
language.A good example is define a Service that validates Domain Objects.
Imagining a scenario where you have a User class that holds email and
password. Email and password fields must be validated, for example,
email as an email and password with at least 6 chars. A generic
validation service could not have the User validation hardcoded inside
the service, so the solution would be an external factor that explains
to service how to validate the DO. One of the possible implementations
would be a UserValidator class that contains validation rules for each
field. This external factor is a good sample of meta-information. But
how would a meta attribute would solve this situation?
A Service could simple retrieve the validation instructions by
Reflecting the class which instance is going to be validated.
Basically, to validate a Domain Object, it is simply required to add
validation rules on desired attributes. Example:class User {
<Email Meta Information>
protected $email;<At least 6 chars Meta Information>
protected $password;
}NOTE: Please understand that this do not enter in any implementation
details. It is not time (yet) to talk baout docblock, new syntax, etc.
Scope now is simpler than that.Now that is possible to see how meta attribute support could benefit a
language, I compiled a simple list of known projects and how can they
benefit of meta support:
- phpUnit Providing meta functionality for test cases, examples:
@dataProvider for test data iteration, @expectedException for catching
exceptions, etc.- Doctrine For Object-Relational mapping, examples: @Entity,
@OneToOne, @Id, etc.- Zend Framework Server classes Used to automate mappings for XML-RPC,
SOAP, etc.- FLOW3 for dependency injection and validation
- Symfony2 for validation and routing rules
- Others: Validation, Functional Behavior injection (which could take
advantage of Traits), etc.Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?
+1 on this poll.
Happy voting!
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi,
I certainly don't have PHP-Karma (Does meritocracy really refer to
that?), but simply I can't believe that you're talking about this, again.
I think Annotation-Supporters have made their point, but shouldn't they
let the PHP 5.4 Developers get on with it and let them roll out a new
version instead of forcing them to reply to lengthy emails about the
same topic over and over again. One could almost believe that you're
hoping to drown their voices by frustrating them into not replying
anymore, therefore winning your vote.
cheers.
Lars
Hi,
I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
but simply I can't believe that you're talking about this, again.I think Annotation-Supporters have made their point, but shouldn't they let
the PHP 5.4 Developers get on with it and let them roll out a new version
instead of forcing them to reply to lengthy emails about the same topic over
and over again. One could almost believe that you're hoping to drown their
voices by frustrating them into not replying anymore, therefore winning your
vote.cheers.
Lars--
^ I agree.
I also don't think you can discuss annotations without simultaneously
discussing their implementation. To me, it looks like you're trying to
force through a vote on a very vague topic "should PHP support
Annotations", and then use that vote later to force through an
implementation that many core people have already said is not
desirable.
Many of the arguments that are central to the question of "should PHP
support Annotations" MUST deal with their implementation because they
add a large new set of syntax to the language.
I doubt anyone would support annotations "at any cost", and yet that's
the vote you're trying to force here.
@Chad: You're getting me wrong here.
If results of poll decide for OK to meta attribute support, next poll
would be which implementation to choose.
I can find 3 different implementations that we can choose, but anyone
is free to contribute.
- Docblock
/** @Foo */
class User { ... }
- New syntax similar to first patch
[Foo]
class User { ... }
- A keyword scope similar to method/namespace declaration
annotate { return new Foo(); }
class User { ... }
But before even spend time talking over and over about implementation,
I wanna ask if we should invest time into it, since I got a lot of
flaming responses (and I still continue, even though people barely see
what I'm asking).
If you say that we should enhance docblock to allow retrieve of @foo,
you're automatically saying +1 to this thread.
I do not want to enter in discussion about implementation because I
don't even know if it will be accepted. I don't want to spend a lot of
time to produce a patch to something that will not be accepted. So
let's decide IF and possibly WHAT to implement, then I can work on it.
All I want is a democratic decision, and not something that one guy
answer as "NO" and end of story.
If majority says "YES", one person being against it doesn't sound to
me like a democracy/meritocracy.
Cheers,
Hi,
I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
but simply I can't believe that you're talking about this, again.I think Annotation-Supporters have made their point, but shouldn't they let
the PHP 5.4 Developers get on with it and let them roll out a new version
instead of forcing them to reply to lengthy emails about the same topic over
and over again. One could almost believe that you're hoping to drown their
voices by frustrating them into not replying anymore, therefore winning your
vote.cheers.
Lars--
^ I agree.
I also don't think you can discuss annotations without simultaneously
discussing their implementation. To me, it looks like you're trying to
force through a vote on a very vague topic "should PHP support
Annotations", and then use that vote later to force through an
implementation that many core people have already said is not
desirable.Many of the arguments that are central to the question of "should PHP
support Annotations" MUST deal with their implementation because they
add a large new set of syntax to the language.I doubt anyone would support annotations "at any cost", and yet that's
the vote you're trying to force here.--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I don't wanna be bad interpreted or considered as rude, but I wonder
why is it so hard for all of you to just vote instead of stay crying
like lost babies.
PHP is open for everyone to contribute, I want to help it but it seems
impossible to help language move forward without people that accept
global decisions.
Cheers,
On Tue, Nov 16, 2010 at 3:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
@Chad: You're getting me wrong here.
If results of poll decide for OK to meta attribute support, next poll
would be which implementation to choose.
I can find 3 different implementations that we can choose, but anyone
is free to contribute.
- Docblock
/** @Foo */
class User { ... }
- New syntax similar to first patch
[Foo]
class User { ... }
- A keyword scope similar to method/namespace declaration
annotate { return new Foo(); }
class User { ... }But before even spend time talking over and over about implementation,
I wanna ask if we should invest time into it, since I got a lot of
flaming responses (and I still continue, even though people barely see
what I'm asking).If you say that we should enhance docblock to allow retrieve of @foo,
you're automatically saying +1 to this thread.
I do not want to enter in discussion about implementation because I
don't even know if it will be accepted. I don't want to spend a lot of
time to produce a patch to something that will not be accepted. So
let's decide IF and possibly WHAT to implement, then I can work on it.All I want is a democratic decision, and not something that one guy
answer as "NO" and end of story.
If majority says "YES", one person being against it doesn't sound to
me like a democracy/meritocracy.Cheers,
Hi,
I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
but simply I can't believe that you're talking about this, again.I think Annotation-Supporters have made their point, but shouldn't they let
the PHP 5.4 Developers get on with it and let them roll out a new version
instead of forcing them to reply to lengthy emails about the same topic over
and over again. One could almost believe that you're hoping to drown their
voices by frustrating them into not replying anymore, therefore winning your
vote.cheers.
Lars--
^ I agree.
I also don't think you can discuss annotations without simultaneously
discussing their implementation. To me, it looks like you're trying to
force through a vote on a very vague topic "should PHP support
Annotations", and then use that vote later to force through an
implementation that many core people have already said is not
desirable.Many of the arguments that are central to the question of "should PHP
support Annotations" MUST deal with their implementation because they
add a large new set of syntax to the language.I doubt anyone would support annotations "at any cost", and yet that's
the vote you're trying to force here.--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I understand where you're coming from, and I appreciate the effort
you've put into this RFC so far, but what I meant is that (although I
don't have karma and won't be voting), if I were to vote, I would
only +1 annotations if they were extremely limited (key=>value pairs).
That's why implementation matters to me - I see the benefit of simple
meta-data retrieval but not an extensive syntax addition to the
language.
I also think that's why you see people suggesting docblock, because
what it already offers is similar to this key=>value metadata
retrieval using the @tag syntax. Really, people are saying they favor
some meta-data retrieval but not the complicated annotations that you
want.
This is why I think you cannot have a vote on annotations in general.
On Tue, Nov 16, 2010 at 9:47 AM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
@Chad: You're getting me wrong here.
If results of poll decide for OK to meta attribute support, next poll
would be which implementation to choose.
I can find 3 different implementations that we can choose, but anyone
is free to contribute.
- Docblock
/** @Foo */
class User { ... }
- New syntax similar to first patch
[Foo]
class User { ... }
- A keyword scope similar to method/namespace declaration
annotate { return new Foo(); }
class User { ... }But before even spend time talking over and over about implementation,
I wanna ask if we should invest time into it, since I got a lot of
flaming responses (and I still continue, even though people barely see
what I'm asking).If you say that we should enhance docblock to allow retrieve of @foo,
you're automatically saying +1 to this thread.
I do not want to enter in discussion about implementation because I
don't even know if it will be accepted. I don't want to spend a lot of
time to produce a patch to something that will not be accepted. So
let's decide IF and possibly WHAT to implement, then I can work on it.All I want is a democratic decision, and not something that one guy
answer as "NO" and end of story.
If majority says "YES", one person being against it doesn't sound to
me like a democracy/meritocracy.Cheers,
Hi,
I certainly don't have PHP-Karma (Does meritocracy really refer to that?),
but simply I can't believe that you're talking about this, again.I think Annotation-Supporters have made their point, but shouldn't they let
the PHP 5.4 Developers get on with it and let them roll out a new version
instead of forcing them to reply to lengthy emails about the same topic over
and over again. One could almost believe that you're hoping to drown their
voices by frustrating them into not replying anymore, therefore winning your
vote.cheers.
Lars--
^ I agree.
I also don't think you can discuss annotations without simultaneously
discussing their implementation. To me, it looks like you're trying to
force through a vote on a very vague topic "should PHP support
Annotations", and then use that vote later to force through an
implementation that many core people have already said is not
desirable.Many of the arguments that are central to the question of "should PHP
support Annotations" MUST deal with their implementation because they
add a large new set of syntax to the language.I doubt anyone would support annotations "at any cost", and yet that's
the vote you're trying to force here.--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I understand where you're coming from, and I appreciate the effort
you've put into this RFC so far, but what I meant is that (although I
don't have karma and won't be voting), if I were to vote, I would
only +1 annotations if they were extremely limited (key=>value pairs).
if that what you want, you should vote +1 for the annotations, or open a new
vote for extending the reflection api to allow getting invidual docblock
tags, or just write a wrapper for the ReflectionProperty::getDocComment.
That's why implementation matters to me - I see the benefit of simple
meta-data retrieval but not an extensive syntax addition to the
language.
thats a question about the implementation. vote for that in the next round.
I also think that's why you see people suggesting docblock, because
what it already offers is similar to this key=>value metadata
retrieval using the @tag syntax.
currently there is very little support for the docblock in the php core
itself, as I mentioned you can only get a whole block through reflection,
and I don't really know, how that got into the language. :)
Really, people are saying they favor
some meta-data retrieval but not the complicated annotations that you
want.
so it seems, that some kind of metadata storing, retrival mechanism is
wanted, thats good to hear.
Tyrael
I understand where you're coming from, and I appreciate the effort
you've put into this RFC so far, but what I meant is that (although I
don't have karma and won't be voting), if I were to vote, I would
only +1 annotations if they were extremely limited (key=>value pairs).if that what you want, you should vote +1 for the annotations, or open a new
vote for extending the reflection api to allow getting invidual docblock
tags
I am a low man on this totem pole, and have no karma at all, but I have to say that makes a great deal of sense to me. Right now, for documenting a codebase, I parse the docblocks in userland to extract @tags. Adding that capability to the Reflection classes sounds quite valuable.
--
Paul M. Jones
http://paul-m-jones.com/
On Tue, 16 Nov 2010 17:37:44 -0000, Chad Fulton chadfulton@gmail.com
wrote:
I also don't think you can discuss annotations without simultaneously
discussing their implementation. To me, it looks like you're trying to
force through a vote on a very vague topic "should PHP support
Annotations", and then use that vote later to force through an
implementation that many core people have already said is not
desirable.Many of the arguments that are central to the question of "should PHP
support Annotations" MUST deal with their implementation because they
add a large new set of syntax to the language.I doubt anyone would support annotations "at any cost", and yet that's
the vote you're trying to force here.
This argument doesn't make any sense. This is a common strategy for
dealing with complex matters.
For instance, in my country laws are first discussed and voted on the
general principles, then it's discussed and voted on the details (possibly
in committees) and finally there's a final overall vote.
--
Gustavo Lopes
Hi!
Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?
Unless there's a simple way of describing it - without adding a lot of
complexity and introducing multiple new syntax constructs - no. Do it in
userspace.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I think my reply ( http://article.gmane.org/gmane.comp.php.devel/63203 )
addresses this. It doesn't introduce any new language constructs per se.
You could make it even more standard and clear by adding "new" after
"annotation".
Just as a thought: instead of annotation, metadata could also be used as
the keyword. I am interested to see what you, Zeev and the others say
about this syntax because I believe it strikes a balance that allows for
metadata usage without messing with the syntax.
I am all for annotations/metadata, but I can certainly see the argument
about syntax: we want to strive for consistency in syntax looking
forward, particularly since PHP isn't well known for consistency (look
at the string and array standard function names :D ).
-Alec
Hi!
Poll will be opened for voting for 7 days (1 week) starting from now.
Poll will be closed next Monday at 5pm GMT.
Question: Does PHP need meta attribute support?Unless there's a simple way of describing it - without adding a lot of
complexity and introducing multiple new syntax constructs - no. Do it in
userspace.
Hi!
I think my reply ( http://article.gmane.org/gmane.comp.php.devel/63203 )
addresses this. It doesn't introduce any new language constructs per se.
You could make it even more standard and clear by adding "new" after
"annotation".
How about making it a full RFC? It's kind of hard to keep track of
things in all threads.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Ok, I will do that. I already have some code examples worked up from
earlier.
I have just registered on the wiki (same email as here). Are you able to
give me access to the rfc namespace so I start the rfc?
Also, do you want me to start a new thread or just post the rfc as a
reply to this thread?
Thanks.
-Alec
Hi!
I think my reply ( http://article.gmane.org/gmane.comp.php.devel/63203 )
addresses this. It doesn't introduce any new language constructs per se.
You could make it even more standard and clear by adding "new" after
"annotation".How about making it a full RFC? It's kind of hard to keep track of
things in all threads.
Hi Stas,
A full RFC will be written based on results of polls.
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
So instead of lose time, I prefer to discuss what can be done here,
write an RFC then finally implement it.
But without having feedback from core developers, it's difficult to
make any decision.
Cheers,
Hi!
I think my reply ( http://article.gmane.org/gmane.comp.php.devel/63203 )
addresses this. It doesn't introduce any new language constructs per se.
You could make it even more standard and clear by adding "new" after
"annotation".How about making it a full RFC? It's kind of hard to keep track of things in
all threads.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
Not entirely true. Patch helps, but with feature this big and complex
having consensus on design before actually implementing it may be better
and save you some time.
As for polls, I think generic "having annotations" poll is not very
useful. It's like having a poll "should we have cool features in PHP?"
Of course we should! The devil is in the details. And so far the details
of this thing contain a significant number of devils we have to handle.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?
The subject is big and I identify at least 5 different discussions
that can diverge.
Cheers,
Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.Not entirely true. Patch helps, but with feature this big and complex having
consensus on design before actually implementing it may be better and save
you some time.
As for polls, I think generic "having annotations" poll is not very useful.
It's like having a poll "should we have cool features in PHP?" Of course we
should! The devil is in the details. And so far the details of this thing
contain a significant number of devils we have to handle.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
In my opinion (as a person with 0 karma), I think that sounds reasonable
because most people are most concerned about the actual implementation
(syntax, performance, apc etc) because I don't think many argue that
Metadata doesn't have value.
What are the 5 different discussion topics you are thinking of, just out
of curiosity?
Also, I can just post my syntax idea as a gist or pastie or something
instead of making an rfc...
-Alec
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?The subject is big and I identify at least 5 different discussions
that can diverge.Cheers,
Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
Not entirely true. Patch helps, but with feature this big and complex having
consensus on design before actually implementing it may be better and save
you some time.
As for polls, I think generic "having annotations" poll is not very useful.
It's like having a poll "should we have cool features in PHP?" Of course we
should! The devil is in the details. And so far the details of this thing
contain a significant number of devils we have to handle.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Alec,
Here is the quick list:
- Where to put the metadata information? docblock or though php code?
- Syntax (based on first decision)
- Return would be an array or object instances
- Compile time or run time (decision is more about APC being able to
cache, but instances being created at runtime automatically or no APC
cache but instances only being created when requested (during
Reflection call) - Named variables for instantiation or method arguments order? How
would we deal with the need of Reflector during constructor if second
sounds better? - Would we support inherited metadata?
Cheers,
In my opinion (as a person with 0 karma), I think that sounds reasonable
because most people are most concerned about the actual implementation
(syntax, performance, apc etc) because I don't think many argue that
Metadata doesn't have value.What are the 5 different discussion topics you are thinking of, just out of
curiosity?Also, I can just post my syntax idea as a gist or pastie or something
instead of making an rfc...-Alec
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?The subject is big and I identify at least 5 different discussions
that can diverge.Cheers,
On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshevsmalyshev@sugarcrm.com
wrote:Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.Not entirely true. Patch helps, but with feature this big and complex
having
consensus on design before actually implementing it may be better and
save
you some time.
As for polls, I think generic "having annotations" poll is not very
useful.
It's like having a poll "should we have cool features in PHP?" Of course
we
should! The devil is in the details. And so far the details of this thing
contain a significant number of devils we have to handle.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Ah, thanks.
This is my proposed syntax and examples of it being used:
https://gist.github.com/702925
Here is my answer to those questions:
- PHP code
- See the gist for syntax
- Return object instances of the annotation because then you can call
methods on the annotation if you need to (it think it would be useful) - Can you APC cache ones that exist at compile time and then not cache
ones that are created at runtime (since they are likely to change
anyways, request to request)? - Method argument order to maintain consistency with PHP syntax. Named
arguments if PHP ever gets 'em. The grammar addition should use the
grammar already there in the grammar file for calling methods so that it
always works with the new way of calling methods and functions. - Yes for inherited metadata as long as you can filter it out (exactly
like in the RFC).
A another comment:
getAnnotation($name) and getAnnotation($name, $type) both have to become
getAnnotations and then always return an array. This makes things more
consistent and allows for multiple metadata structures for each method.
The gist I posted would be a fully working API (albeit very basic with
no proper error/exception handling) if the url parsing code was put in,
but I left it out for brevity.
Opinions?
-Alec
Hi Alec,
Here is the quick list:
- Where to put the metadata information? docblock or though php code?
- Syntax (based on first decision)
- Return would be an array or object instances
- Compile time or run time (decision is more about APC being able to
cache, but instances being created at runtime automatically or no APC
cache but instances only being created when requested (during
Reflection call)- Named variables for instantiation or method arguments order? How
would we deal with the need of Reflector during constructor if second
sounds better?- Would we support inherited metadata?
Cheers,
In my opinion (as a person with 0 karma), I think that sounds reasonable
because most people are most concerned about the actual implementation
(syntax, performance, apc etc) because I don't think many argue that
Metadata doesn't have value.What are the 5 different discussion topics you are thinking of, just out of
curiosity?Also, I can just post my syntax idea as a gist or pastie or something
instead of making an rfc...-Alec
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?The subject is big and I identify at least 5 different discussions
that can diverge.Cheers,
On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshevsmalyshev@sugarcrm.com
wrote:Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
Not entirely true. Patch helps, but with feature this big and complex
having
consensus on design before actually implementing it may be better and
save
you some time.
As for polls, I think generic "having annotations" poll is not very
useful.
It's like having a poll "should we have cool features in PHP?" Of course
we
should! The devil is in the details. And so far the details of this thing
contain a significant number of devils we have to handle.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I like the idea, Alec.
My only question is, syntactically, what difference would using a keyword,
in this case "attribute", as opposed to brackets "[]"?
Ah, thanks.
This is my proposed syntax and examples of it being used:
https://gist.github.com/702925Here is my answer to those questions:
- PHP code
- See the gist for syntax
- Return object instances of the annotation because then you can call
methods on the annotation if you need to (it think it would be useful)- Can you APC cache ones that exist at compile time and then not cache ones
that are created at runtime (since they are likely to change anyways,
request to request)?- Method argument order to maintain consistency with PHP syntax. Named
arguments if PHP ever gets 'em. The grammar addition should use the grammar
already there in the grammar file for calling methods so that it always
works with the new way of calling methods and functions.- Yes for inherited metadata as long as you can filter it out (exactly like
in the RFC).A another comment:
getAnnotation($name) and getAnnotation($name, $type) both have to become
getAnnotations and then always return an array. This makes things more
consistent and allows for multiple metadata structures for each method.The gist I posted would be a fully working API (albeit very basic with no
proper error/exception handling) if the url parsing code was put in, but I
left it out for brevity.Opinions?
-Alec
Hi Alec,
Here is the quick list:
- Where to put the metadata information? docblock or though php code?
- Syntax (based on first decision)
- Return would be an array or object instances
- Compile time or run time (decision is more about APC being able to
cache, but instances being created at runtime automatically or no APC
cache but instances only being created when requested (during
Reflection call)- Named variables for instantiation or method arguments order? How
would we deal with the need of Reflector during constructor if second
sounds better?- Would we support inherited metadata?
Cheers,
In my opinion (as a person with 0 karma), I think that sounds reasonable
because most people are most concerned about the actual implementation
(syntax, performance, apc etc) because I don't think many argue that
Metadata doesn't have value.What are the 5 different discussion topics you are thinking of, just out
of
curiosity?Also, I can just post my syntax idea as a gist or pastie or something
instead of making an rfc...-Alec
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?The subject is big and I identify at least 5 different discussions
that can diverge.Cheers,
On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshevsmalyshev@sugarcrm.com
wrote:Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
Not entirely true. Patch helps, but with feature this big and complex
having
consensus on design before actually implementing it may be better and
save
you some time.
As for polls, I think generic "having annotations" poll is not very
useful.
It's like having a poll "should we have cool features in PHP?" Of
course
we
should! The devil is in the details. And so far the details of this
thing
contain a significant number of devils we have to handle.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
I like the idea, Alec.
My only question is, syntactically, what difference would using a keyword,
in this case "attribute", as opposed to brackets "[]"?
I would say that it provides better searchability -- it's easier for
people new to the feature to recognise what it means, and to search for
how to use it. I for one didn't understand what []-style annotations
were when I first saw them, and had no idea how to find out what it meant.
D
Ah, thanks.
This is my proposed syntax and examples of it being used:
https://gist.github.com/702925Here is my answer to those questions:
- PHP code
- See the gist for syntax
- Return object instances of the annotation because then you can call
methods on the annotation if you need to (it think it would be useful)- Can you APC cache ones that exist at compile time and then not cache ones
that are created at runtime (since they are likely to change anyways,
request to request)?- Method argument order to maintain consistency with PHP syntax. Named
arguments if PHP ever gets 'em. The grammar addition should use the grammar
already there in the grammar file for calling methods so that it always
works with the new way of calling methods and functions.- Yes for inherited metadata as long as you can filter it out (exactly like
in the RFC).A another comment:
getAnnotation($name) and getAnnotation($name, $type) both have to become
getAnnotations and then always return an array. This makes things more
consistent and allows for multiple metadata structures for each method.The gist I posted would be a fully working API (albeit very basic with no
proper error/exception handling) if the url parsing code was put in, but I
left it out for brevity.Opinions?
-Alec
Hi Alec,
Here is the quick list:
- Where to put the metadata information? docblock or though php code?
- Syntax (based on first decision)
- Return would be an array or object instances
- Compile time or run time (decision is more about APC being able to
cache, but instances being created at runtime automatically or no APC
cache but instances only being created when requested (during
Reflection call)- Named variables for instantiation or method arguments order? How
would we deal with the need of Reflector during constructor if second
sounds better?- Would we support inherited metadata?
Cheers,
In my opinion (as a person with 0 karma), I think that sounds reasonable
because most people are most concerned about the actual implementation
(syntax, performance, apc etc) because I don't think many argue that
Metadata doesn't have value.What are the 5 different discussion topics you are thinking of, just out
of
curiosity?Also, I can just post my syntax idea as a gist or pastie or something
instead of making an rfc...-Alec
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?The subject is big and I identify at least 5 different discussions
that can diverge.Cheers,
On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshevsmalyshev@sugarcrm.com
wrote:Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
Not entirely true. Patch helps, but with feature this big and complex
having
consensus on design before actually implementing it may be better and
save
you some time.
As for polls, I think generic "having annotations" poll is not very
useful.
It's like having a poll "should we have cool features in PHP?" Of
course
we
should! The devil is in the details. And so far the details of this
thing
contain a significant number of devils we have to handle.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Fair enough. I'm bias towards the C# annotation syntax, so that's my
attraction to it.
I like the idea, Alec.
My only question is, syntactically, what difference would using a
keyword,
in this case "attribute", as opposed to brackets "[]"?
I would say that it provides better searchability -- it's easier for
people new to the feature to recognise what it means, and to search for
how to use it. I for one didn't understand what []-style annotations
were when I first saw them, and had no idea how to find out what it meant.D
Ah, thanks.
This is my proposed syntax and examples of it being used:
https://gist.github.com/702925Here is my answer to those questions:
- PHP code
- See the gist for syntax
- Return object instances of the annotation because then you can call
methods on the annotation if you need to (it think it would be useful)- Can you APC cache ones that exist at compile time and then not cache
ones
that are created at runtime (since they are likely to change anyways,
request to request)?- Method argument order to maintain consistency with PHP syntax. Named
arguments if PHP ever gets 'em. The grammar addition should use the
grammar
already there in the grammar file for calling methods so that it always
works with the new way of calling methods and functions.- Yes for inherited metadata as long as you can filter it out (exactly
like
in the RFC).A another comment:
getAnnotation($name) and getAnnotation($name, $type) both have to become
getAnnotations and then always return an array. This makes things more
consistent and allows for multiple metadata structures for each method.The gist I posted would be a fully working API (albeit very basic with
no
proper error/exception handling) if the url parsing code was put in, but
I
left it out for brevity.Opinions?
-Alec
Hi Alec,
Here is the quick list:
- Where to put the metadata information? docblock or though php code?
- Syntax (based on first decision)
- Return would be an array or object instances
- Compile time or run time (decision is more about APC being able to
cache, but instances being created at runtime automatically or no APC
cache but instances only being created when requested (during
Reflection call)- Named variables for instantiation or method arguments order? How
would we deal with the need of Reflector during constructor if second
sounds better?- Would we support inherited metadata?
Cheers,
On Wed, Nov 17, 2010 at 12:33 AM, Alec Gorgealecgorge@gmail.com
wrote:In my opinion (as a person with 0 karma), I think that sounds
reasonable
because most people are most concerned about the actual implementation
(syntax, performance, apc etc) because I don't think many argue that
Metadata doesn't have value.What are the 5 different discussion topics you are thinking of, just
out
of
curiosity?Also, I can just post my syntax idea as a gist or pastie or something
instead of making an rfc...-Alec
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?The subject is big and I identify at least 5 different discussions
that can diverge.Cheers,
On Wed, Nov 17, 2010 at 12:26 AM, Stas Malyshev<
smalyshev@sugarcrm.com>
wrote:Hi!
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
Not entirely true. Patch helps, but with feature this big and
complex
having
consensus on design before actually implementing it may be better
and
save
you some time.
As for polls, I think generic "having annotations" poll is not very
useful.
It's like having a poll "should we have cool features in PHP?" Of
course
we
should! The devil is in the details. And so far the details of this
thing
contain a significant number of devils we have to handle.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Of course not. Assuming meta support requires substantial additions of syntax then it's very far from consensus.
A more productive approach would be coming up with ways to do it with existing functionality (maybe with some minor additions), which makes phpdoc a natural option to look at (even if it's not the incarnation of the perfect annotations solution).
Zeev
On Nov 17, 2010, at 4:29, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?Of course not. Assuming meta support requires substantial additions of
syntax then it's very far from consensus.A more productive approach would be coming up with ways to do it with
existing functionality (maybe with some minor additions), which makes phpdoc
a natural option to look at (even if it's not the incarnation of the perfect
annotations solution).Zeev
internals@lists.php.net/msg47732.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg47732.html
you said that before.
and this is where the discussion started about the alternative syntax and
implementation.
you said, that you see the usefulness, you just don't think that it worths
the complexity and the new syntax.
if that so, then I can't see, why can't we move on from the why is this
useful to the how and what should we implement.
in the end, it would only gets in to the trunk if the prominent coredevs(as
you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing
the discussion about this feature.
Tyrael
I think everyone is jumping the gun on this. Let's let Alec, et al. finish
the newly proposed RFC and then argue about it. If the consensus is still
that the complexity and drag in the introduced syntax outweighs the
benefits, we put it to bed or try again. Fair enough?
On Nov 17, 2010, at 4:29, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?Of course not. Assuming meta support requires substantial additions of
syntax then it's very far from consensus.A more productive approach would be coming up with ways to do it with
existing functionality (maybe with some minor additions), which makes
phpdoc
a natural option to look at (even if it's not the incarnation of the
perfect
annotations solution).Zeev
internals@lists.php.net/msg47732.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg47732.html
you said that before.
and this is where the discussion started about the alternative syntax and
implementation.
you said, that you see the usefulness, you just don't think that it worths
the complexity and the new syntax.
if that so, then I can't see, why can't we move on from the why is this
useful to the how and what should we implement.
in the end, it would only gets in to the trunk if the prominent coredevs(as
you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing
the discussion about this feature.Tyrael
--
Thanks,
Will Fitch
Director of Operations | Quepasa.com
931.205.8242 | will.fitch@quepasacorp.com
Twitter: twitter.com/willfitch
I’m not the only one in this thread repeating himself to make a point :)
What I opposed is the notion that ‘everyone wants some sort of meta attribute support’. Maybe I read too much into it but I read it as implying we need something substantial that’s new.
Either way, I’m fine with going in this way as long as the high-level-direction of not adding a large amount of syntax is clear.
Zeev
internals@lists.php.net/msg47732.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg47732.html
you said that before.
and this is where the discussion started about the alternative syntax and implementation.
you said, that you see the usefulness, you just don't think that it worths the complexity and the new syntax.
if that so, then I can't see, why can't we move on from the why is this useful to the how and what should we implement.
in the end, it would only gets in to the trunk if the prominent coredevs(as you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing the discussion about this feature.
Now that's something we can agree on :D
We can reduce the syntax added to simply being the attribute tag before
the standard syntax for a function call/class creation.
This means functions can be attributes too (as if that is useful...)!
This is a function being used as an attribute
attribute functionAttr("test")
public function Test() {
...
or a class
attribute new ClassAttr("Test")
public function Test() {
...
Does that lower the syntax bar enough?
-Alec
I’m not the only one in this thread repeating himself to make a point :)
What I opposed is the notion that ‘everyone wants some sort of meta attribute support’. Maybe I read too much into it but I read it as implying we need something substantial that’s new.
Either way, I’m fine with going in this way as long as the high-level-direction of not adding a large amount of syntax is clear.
Zeev
internals@lists.php.net/msg47732.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg47732.html
you said that before.
and this is where the discussion started about the alternative syntax and implementation.
you said, that you see the usefulness, you just don't think that it worths the complexity and the new syntax.
if that so, then I can't see, why can't we move on from the why is this useful to the how and what should we implement.
in the end, it would only gets in to the trunk if the prominent coredevs(as you, Rasmus, etc.) accept it, so I don't know why are you afraid continuing the discussion about this feature.
-1
I won't be using it. I won't argue on this thread since it is a +/-
vote on the idea of Annotations, not the proposed implementation of
it.
Hi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka. Annotations) discussion.
Completely ignoring the actual issue, just in response to the subject:
We should focus on getting 5.4 out. And not delay it for this. Rather go
for a model with more frequent feature releases. (I mentioned multiple
times that I'd like a Ubuntu-like model with releases all N months and
every Mth release is a "long term" (whatever long means) supported
version. Release branches should get finalized features only. This would
give early access to new features thus motivating contributors while
distributors know what they can use as a base) But this deserves it's
own discussion. So for this thread: Feel free to discuss this subject,
but not targeting 5.4 as said in the subject.
johannes
Hi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka. Annotations) discussion.Completely ignoring the actual issue, just in response to the subject:
We should focus on getting 5.4 out. And not delay it for this. Rather go
for a model with more frequent feature releases. (I mentioned multiple
times that I'd like a Ubuntu-like model with releases all N months and
every Mth release is a "long term" (whatever long means) supported
version. Release branches should get finalized features only. This would
give early access to new features thus motivating contributors while
distributors know what they can use as a base) But this deserves it's
own discussion. So for this thread: Feel free to discuss this subject,
but not targeting 5.4 as said in the subject.
Right, there is no way this will be ready for next week's alpha.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug