Hi!
Look at the xdoclet fiasco, that should finish to convince you that
phpdoc has nothing to do with annotations.
It would be useful if, for those unfamiliar with xdoclet history, you
would explain why it was a fiasco.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.
hi,
On Thu, Sep 16, 2010 at 10:51 PM, Matthew Weier O'Phinney
wrote:
> (I'm still not entirely convinced that the same goals could not be achieved
> via
> code written on top of a docblock parser extension.)
Look at the xdoclet fiasco, that should finish to convince you that
phpdoc has nothing
On Thu Sep 16 02:44 PM, Stas Malyshev wrote:
>
> WTF is "Annotations"? We didn't define it yet. Should PHP support
http://en.wikipedia.org/wiki/.NET_metadata
http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx
.NET calls this attribut
On 2010-09-16, Guilherme Blanco wrote:
> On Thu, Sep 16, 2010 at 5:07 PM, Stas Malyshev wrote:
> > > Again, you change the meanings of something I write.
> > > I do not want Java Annotations on PHP. But I want a clean way to
> > > include metadata mapping on my class/property/method/function.
> >
Olá!
On Thu, Sep 16, 2010 at 5:07 PM, Stas Malyshev wrote:
> Hi!
>
>> Again, you change the meanings of something I write.
>> I do not want Java Annotations on PHP. But I want a clean way to
>> include metadata mapping on my class/property/method/function.
>
> Everybody wants a clean way to inclu
I know this is drive-by/chiming in, but we've had this discussion with
the ZF community. While @expectedExcpetion is a feature of PHPUnit that
has been picked up and used by developers over the past few years, it
semantically makes no sense, and we have since outlawed its usage.
Why? B/c a "c
Hi!
Again, you change the meanings of something I write.
I do not want Java Annotations on PHP. But I want a clean way to
include metadata mapping on my class/property/method/function.
Everybody wants a clean way to include metadata. It's *what* this way is
where the difference is. So is the
Hi Stas,
On Thu, Sep 16, 2010 at 4:20 PM, Stas Malyshev wrote:
> Hi!
>
>> I mean that any code packer can degrade the the functionality of your
>> app. Example:
>
> Fix your "code packer" not to do that.
>
>> I didn't mean we should stop the discussion. I meant that like many
>> others over the y
Hi!
Overloading comment syntax to modify application functionality is the
worst idea I've seen suggested on this list. This beats goto by miles.
What you mean "suggested"? It's what happening right now in pretty much
any widely used framework.
"Why's my stuff broke? That stack trace leads
Hi!
I mean that any code packer can degrade the the functionality of your
app. Example:
Fix your "code packer" not to do that.
I didn't mean we should stop the discussion. I meant that like many
others over the years lead to nowhere if we don't take the correct
action: vote.
How it's the c
On 09/16/2010 11:44 AM, Stas Malyshev wrote:
> Hi!
>
>> Again, we should not consider docblock mainly because I think
>> adding/removing comments of your code should NEVER modify the overall
>> functionality of your application.
>
> It's a circular argument - "we can't use docblocks because docbl
Hi Stas,
On Thu, Sep 16, 2010 at 3:44 PM, Stas Malyshev wrote:
> Hi!
>
>> Again, we should not consider docblock mainly because I think
>> adding/removing comments of your code should NEVER modify the overall
>> functionality of your application.
>
> It's a circular argument - "we can't use docbl
Hi!
Again, we should not consider docblock mainly because I think
adding/removing comments of your code should NEVER modify the overall
functionality of your application.
It's a circular argument - "we can't use docblocks because docblocks
shouldn't be used". They are not "comments" if you do
-1 for the proposed Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks, minor note: should not be not called
"getAnnotations"
On Thu Sep 16 01:01 PM, Lars Schultz wrote:
> +1 for adding APIs to parse doc blocks
> -1 for introducing a new Annotations concept and assoc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/09/10 18:00, Zeev Suraski wrote:
> At 16:34 16/09/2010, Guilherme Blanco wrote:
>> So the question to be answered is: Should PHP support Annotations?
>
> -1 for introducing a new Annotations concept and associated syntax
>
> +1 for adding APIs
+1 for adding APIs to parse doc blocks
-1 for introducing a new Annotations concept and associated syntax
Am 16.09.2010 18:36, schrieb Wim Godden:
I'm going to say exactly the same thing :
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
On 16 September 2010 22:34, Guilherme Blanco wrote:
> So the question to be answered is: Should PHP support Annotations?
-1 on annotations.
+0 on new docblock parsing APIs.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: Thursday, September 16, 2010 9:01 AM
To: Guilherme Blanco
Cc: Gustavo Lopes; Derick Rethans; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
>+1 for adding APIs to parse doc blocks
&g
I'm going to say exactly the same thing :
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
Zeev Suraski wrote:
At 16:34 16/09/2010, Guilherme Blanco wrote:
So the question to be answered is: Should PHP support Annotations?
-1 for int
+1 for Annotations
2010/9/16 Guilherme Blanco
> Hi Derick,
>
> Again, we should not consider docblock mainly because I think
> adding/removing comments of your code should NEVER modify the overall
> functionality of your application.
> That said, docblock is no option. Now PLEASE let's stop argu
+1 for annotations
-1/2 for parsing comments - it just doesn't seem right
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: 16 September 2010 17:01
To: Guilherme Blanco
Cc: Gustavo Lopes; Derick Rethans; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP Annota
On Thu, 16 Sep 2010 15:34:05 +0100, Guilherme Blanco
wrote:
Hi Derick,
Again, we should not consider docblock mainly because I think
adding/removing comments of your code should NEVER modify the overall
functionality of your application.
That said, docblock is no option. Now PLEASE let's sto
At 16:34 16/09/2010, Guilherme Blanco wrote:
So the question to be answered is: Should PHP support Annotations?
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
For me, the syntax, or at least the complexity, is important. I like
the idea of metadata, but what I found attractive about the docBlock
parsing was that it only allowed key/value pairs of meta-data.
-1 for annotations in which the engine instantiates arbitrary
annotation objects.
On Thu, Sep 16
>
> So the question to be answered is: Should PHP support Annotations?
>
> I'm +1.
>
+1
Greetings,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Derick,
Again, we should not consider docblock mainly because I think
adding/removing comments of your code should NEVER modify the overall
functionality of your application.
That said, docblock is no option. Now PLEASE let's stop arguing for
nothing and vote?
I'd recommend that since syntax is
On Thu, 16 Sep 2010 14:57:01 +0100, Derick Rethans wrote:
There should be overwhelmingly strong reasons to add a whole new branch
of syntax to PHP, I for one don't see the huge gain annotations bring
on top of PHPDoc.
The only thing I can think of is added the storing of docblock data for
On Mon, 13 Sep 2010, Zeev Suraski wrote:
> I'm not sure we've seen a good reason to add annotations instead of using
> PHPDoc. Sure, PHPDoc isn't a perfect fit for certain purposes, but I think it
> certainly falls in the good-enough fit for most purposes. It's also both
> machine and human read
On Mon, Sep 13, 2010 at 5:59 PM, Zeev Suraski wrote:
> I think great frameworks can be created in PHP w/o annotations (there are
> numerous live examples attesting to that) - and the bang/buck of introducing
> this whole new concept and the associated complexity to everyone is not
> high.
To quo
Am 13.09.2010 20:35, schrieb Benjamin Eberlei:
Developers are clearly not using doc blocks for their static
configuration needs currently, even though the possibility exists. It
just feels wrong.
incidentally, I do;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
On Mon, 13 Sep 2010 21:51:32 +0100, Stas Malyshev
wrote:
If I'm not mistaken, the current implementation instantiates an object
each time getAnnotation() is called, but it was proposed to change this
into a lazy-loading mechanism with the same instance returned every time
for each annotation.
Hi!
If I'm not mistaken, the current implementation instantiates an object
each time getAnnotation() is called, but it was proposed to change this
into a lazy-loading mechanism with the same instance returned every time
for each annotation. In that case, we'd only need to validate that one
time.
On Mon, 13 Sep 2010 21:02:34 +0100, Stas Malyshev
wrote:
Hi!
The best (in the sense of "most similar to what we have today") syntax I
can think of is to define annotations exactly the same way was you'd
define arrays, but replace "array" with the annotation name (plus a
prefix). I think thi
Hi!
The best (in the sense of "most similar to what we have today") syntax I
can think of is to define annotations exactly the same way was you'd
define arrays, but replace "array" with the annotation name (plus a
prefix). I think this looks like PHP:
We have here at least two non-PHP construc
On Mon, 13 Sep 2010 19:20:31 +0100, Stas Malyshev
wrote:
The proposed annotations are basically object instances that are
returned when you call getAnnotations. There are no itemized lists of
rules. I
don't see how this is complex.
They aren't just object instances, since they also have
Strictly speaking yes, you can implement everything you want with PHP
Docblocks. But that argument is comparable to telling a nearly blind man
that his glasses are good enough although a more suited treatment
exists. Just because there exists an approach that stumbles half the way
in a bad way, sho
Hi!
PHPDocs are for what their name suggests, for comments, not for runtime
code information. They allow arbitrary characters, their intent is for
human-readible documentation only.
Nothing prevents us from using phpdocs for non-human-reading purposes.
Actually, there is quite a lot of code t
At 19:25 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 17:46:42 +0100, Zeev Suraski wrote:
I wasn't talking about the patch, I was talking about the need of end
users to understand yet another new concept and syntax. PHP used to be
a language one could pick up over a weekend. I'm hap
Hi!
- LSB. Can you explain from the top of your head when when the called
scope is reset or not (e.g. with parent::, self::, className::, possibly
in non-static contexts) in a function call? I can't.
It's not that hard. Keywords forward, classnames don't.
- Namespaces. It takes a while to me
Hi Zeev,
On Mon, Sep 13, 2010 at 12:44 PM, Zeev Suraski wrote:
> Benjamin,
>
> Strictly speaking annotations are not *needed*. They simply aren't - you
> can do anything and everything you might want to do without them. You can
> argue that the value they bring is very important, and that it ou
Hello Rasmus,
Isn't any configuration by xml or ini files runtime configuration? Any
configuration that is not resulting in code being generated or code
being op-code cached will be-executed on every single request. That
applies to almost any configuration mechanism used in PHP applications.
Sure
On Mon, 13 Sep 2010 17:46:42 +0100, Zeev Suraski wrote:
I wasn't talking about the patch, I was talking about the need of end
users to understand yet another new concept and syntax. PHP used to be
a language one could pick up over a weekend. I'm happy it didn't
stagnate and stay where
Hi!
[ExpectedException("InvalidArgumentException")]
[ExpectedException("InvalidArgumentException", "Expected message", 40")]
[Validation(array("type" => "EMail", "options" => array("checkMX" =>
true))]
This doesn't look like PHP code. In PHP code, nether [] by itself, nor
[ClassName('string
On 9/13/10 8:38 AM, Benjamin Eberlei wrote:
> The primary target for annotations are framework and library integrations:
> validation, forms, metadata mapping, static mvc configuration such as
> routing, view selection or acls. Why do these features not exist with
> current php libraries yet? Becau
At 17:51 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
The fact that PHP is not C# or Java doesn't mean we shouldn't look for
useful features in those languages,
Right.
so it's not an argument.
I think it is very much an argument - the fact a fea
On Mon, 13 Sep 2010 16:59:13 +0100, Zeev Suraski wrote:
At 17:51 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actu
At 17:51 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actually am (either that or get what you want done in some othe
At 17:47 13/09/2010, Benjamin Eberlei wrote:
This only applies to the weird suggestions of % or ! for the operator and
new syntax constructs for arrays and such. Are there any objections to
implementing them to actually look like PHP code?
Yep. It's a whole new branch of syntax even w/o the we
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actually am (either that or get what you want done in some other
way). It's a rare enough use case that
Hi Benjamin,
I agree with you 100 percent.
Greetings,
Christian
On Mon, 13 Sep 2010 17:38:37 +0200, Benjamin Eberlei
wrote:
> I strongly disagree!
>
> PHPDocs are for what their name suggests, for comments, not for runtime
> code information. They allow arbitrary characters, their intent is fo
On Mon, 13 Sep 2010 17:28:47 +0200, Zeev Suraski wrote:
> At 16:39 13/09/2010, Pierre Joye wrote:
>>You are not serioulsy suggesting to use phpdoc for runtime annotation
>>support? Are you?
>
> I actually am (either that or get what you want done in some other
> way). It's a rare enough
Benjamin,
Strictly speaking annotations are not *needed*. They simply aren't -
you can do anything and everything you might want to do without
them. You can argue that the value they bring is very important, and
that it outweighs the complexity they bring upon to the language - in
which cas
I strongly disagree!
PHPDocs are for what their name suggests, for comments, not for runtime
code information. They allow arbitrary characters, their intent is for
human-readible documentation only.
Yet they are used for service description (Zend_Soap_Autodiscover,
Zend_XmlRpc), metadata
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actually am (either that or get what you want done in some other
way). It's a rare enough use case that I think it's a very
reasonable compromise. The disadvanta
hi,
On Mon, Sep 13, 2010 at 3:05 PM, Zeev Suraski wrote:
> I'm not sure we've seen a good reason to add annotations instead of using
> PHPDoc. Sure, PHPDoc isn't a perfect fit for certain purposes, but I think
> it certainly falls in the good-enough fit for most purposes. It's also both
> mach
On 09/13/2010 09:05 AM, Zeev Suraski wrote:
> I for one don't see the huge gain annotations bring on top of PHPDoc.
Same here, I am satisfied with the way that annotations work, for
instance, in PHPUnit.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebast
At 20:24 11/09/2010, Pierre Joye wrote:
On Sat, Sep 11, 2010 at 8:19 PM, Stas Malyshev wrote:
> Hi!
>
>> The separator never was a problem... but I definately don't want to
>> see another 6 months just to define what would the separator be.
>> If we need to drop [] in favor of array support, I v
Hi All,
There seems to be a lot of discussion as to syntax for annotations at
the moment. Firstly I'd like to say that I've never delved into PHP
internals so may not understand some of the reasons why some of my
suggestions may not work, so please don't give me a hard time about it!
I also
On Sun, 12 Sep 2010 11:55:16 -0700, Stas Malyshev
wrote:
> Hi!
>
>> 1. In Java annotations are a special type of an interface. But due the
>> lack of type hinting for scalar values we cannot use this construct,
>> because we cannot put some validation logic in an interface. My proposal
>
> I'm n
Hi!
1. In Java annotations are a special type of an interface. But due the
lack of type hinting for scalar values we cannot use this construct,
because we cannot put some validation logic in an interface. My proposal
I'm not sure I understand - what scalar type hints have to do with it?
Anyway
Hello Sebastian.
On Sun, Sep 12, 2010 at 2:34 PM, Sebastian Bergmann wrote:
> On 09/11/2010 02:24 PM, Pierre Joye wrote:
>> It seems that there is a misunderstanding about the goals of the
>> annotations. They are not meant to be read by human being
>> (javadoc/phpdoc/etc. are) but to be parsed a
On 09/11/2010 02:24 PM, Pierre Joye wrote:
> It seems that there is a misunderstanding about the goals of the
> annotations. They are not meant to be read by human being
> (javadoc/phpdoc/etc. are) but to be parsed automatically to be used
> for services.
Annotations are part of the code and code
Hi Stas,
this type of annotations cannot be used as PHPDoc annotations due its
different syntax. In other languages like Java, C# or AS3 annotations
are an independent language construct and I think in PHP it should be
the same. I dont know how many non-performant user-land
implementations(hacks)
Hi!
It seems that there is a misunderstanding about the goals of the
annotations. They are not meant to be read by human being
(javadoc/phpdoc/etc. are) but to be parsed automatically to be used
for services.
If it's for services/phpdoc, why can't it be part of phpdoc?
I see here a whole new
Hey everyone,
I want to re-drop my proposal onto the table that is just a shortcut
notation for php class instantiation inside that brackets (omiting the
new keyword):
annotation := [className(classArgs*)]
classArgs := array | string | int | float | ...
Re-pasting my examples (this time from sim
On Sat, Sep 11, 2010 at 8:19 PM, Stas Malyshev wrote:
> Hi!
>
>> The separator never was a problem... but I definately don't want to
>> see another 6 months just to define what would the separator be.
>> If we need to drop [] in favor of array support, I vote for ! as
>> separator.
>
> The separat
Hi!
The separator never was a problem... but I definately don't want to
see another 6 months just to define what would the separator be.
If we need to drop [] in favor of array support, I vote for ! as separator.
The separator is not a problem (even though 1-char one produces much
less clutte
Hi Stas and Christian,
The separator never was a problem... but I definately don't want to
see another 6 months just to define what would the separator be.
If we need to drop [] in favor of array support, I vote for ! as separator.
!Author("Guilherme Blanco")
!Validation(!Email(checkMX = true))
Hi,
>> %Annotation(%Email(checkMX = true));
at first I thought what for an ugly syntax. But after a time I think it
is regardless of whether the % or @(from Java, which I prefer over all,
if it were possible) syntax is used. It looks very similar. So I prefer
the % syntax so we can use the [] fo
Hi Stas,
Annotations is a new concept in PHP (even if some framework already
use an user space implementation of them) and I think it is normal
that people will have to read a little bit about this eventually new
feature before using it. This is the same thing for traits, if you
don't know what is
Hi!
[Validation(Email(checkMX=>true))] looks better.
Even here it's not clear what is happening. What is "Validation", what
is "Email", what is "checkMX" (are they all classes? or only some of
them?), what is happening to them (are these classes being instantiated?
when? what is passed as p
>
> [Validation(Email(checkMX=>true))] looks better.
>
> Thanks. Dmitry.
>
Hi Dmitry
The initial syntax proposed in the RFC/Patch is inspired by C#. If you
modify this syntax to remove brackets in nested annotations you will
have some conflicts like this one :
[Validation(Email)]
In this case t
Hi Guilherme,
Guilherme Blanco wrote:
Hi Dmitry,
Comments goes inline.
On Wed, Sep 8, 2010 at 10:56 AM, Dmitry Stogov wrote:
Pierrick Charron wrote:
Hi Dmitry,
First thanks for having a look at the patch and taking some time to
give your feedback ! It's much appreciated
2010/9/8 Dmitry S
Hello Stas,
I agree, using an array like syntax would make the intent much clearer
in the context of PHP, the syntax is just slightly more verbose:
[JoinTable(array(
"name" => "users_phonenumbers",
"joinColumns" => array(
array("name" => "user_id", "referendedColumnName" => "id"),
),
Hi!
[JoinTable(
name="users_phonenumbers",
joinColumns=array(
[JoinColumn(name="user_id", referencedColumnName="id")]
),
inverseJoinColumns=array(
[JoinColumn(name="phonenumber_id", referencedColumnName="id",
unique=true)]
)
)]
[Validation([Email(checkMX
Hi Johannes,
Comments inline.
2010/9/8 Johannes Schlüter :
> Hi,
>
> On Wed, 2010-09-08 at 13:44 -0300, Guilherme Blanco wrote:
>> >>> 2) I suppose that usage of annotation would be quite rare case. I don't
>> >>> think it make sense to extend each op_array, property and class with
>> >>> additio
Hi,
On Wed, 2010-09-08 at 13:44 -0300, Guilherme Blanco wrote:
> >>> 2) I suppose that usage of annotation would be quite rare case. I don't
> >>> think it make sense to extend each op_array, property and class with
> >>> additional "annotations" field. I think it's possible to have a separate
> >
Hi Dmitry,
Comments goes inline.
On Wed, Sep 8, 2010 at 10:56 AM, Dmitry Stogov wrote:
>
>
> Pierrick Charron wrote:
>>
>> Hi Dmitry,
>>
>> First thanks for having a look at the patch and taking some time to
>> give your feedback ! It's much appreciated
>>
>> 2010/9/8 Dmitry Stogov :
>>>
>>> Hi
78 matches
Mail list logo
