# PHP Annotations RFC + Patch

- Thread: https://externals.io/message/49645
- Original archive: https://news-web.php.net/php.internals/49645
- Started by Nate Abele on 2010-09-14T17:25:42+00:00
- Messages: 34
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/49645.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #49645 — Nate Abele — 2010-09-14T17:25:42+00:00

URL: https://externals.io/message/49645#49645

> > […]
> 
> > […]
> 
> 
> You misunderstood me. When I say the frameworks use annotation I don't  
> mean they use annotations in their own implementation (that's not  
> particularly relevant for the reason you present).
> 
> What I mean is that the frameworks recognize annotations the application  
> code has so that the framework user can do stuff like injecting objects,  
> run methods in transactions or check post-conditions in a declarative  
> fashion, by adding annotations.
> 
> By the way, you ignored the rest of the e-mail.
> 
> How do you evaluate the complexity/return of features such as annotations  
> with that of e.g. LSB? Why are they not adequate for PHP, but may be for  
> other languages?

I do not understand this.

I see no one other than Symfony / Doctrine people pushing for this annotations patch.

How can this special-purpose feature (which would add entirely new language semantics in the form of an embedded micro-language) even be open for discussion, when other, more generally-useful RFCs like http://wiki.php.net/rfc/shortsyntaxforarrays were shot down on the basis that they were hard to read and confusing for new developers?

Sorry, but I don't see how this is even remotely close to being appropriate for PHP. Maybe I'm missing something. :-)

Thanks,
- Nate

---

## #49646 — Jonathan Bond-Caron — 2010-09-14T18:30:01+00:00

URL: https://externals.io/message/49645#49646 · In reply to: #49645

> 
> Sorry, but I don't see how this is even remotely close to being 
> appropriate for PHP. Maybe I'm missing something. :-)
> 

I agree, the use cases are just not there

Though maybe some form of "annotations" could be useful in php as a
"pluggable type":
http://bartoszmilewski.wordpress.com/2009/01/18/java-pluggable-types/

But this isn't an annotation as just plain metadata, the parser could do
something with the annotation.

i.e.

class Phone {

   @ReadOnly
   public $id;

   @PhoneNumber
   public $number;
}

class PhoneNumber implements TypeAnnotation {

   static function getTypeValue($val)
   {
      return preg_replace('~[^0-9]~', '', $val);
   }
}

Instead of ~

class Phone {

   protected $_number;

   function __get($prop) {
     if($prop === 'number')
       return $this->_number;
   }
 
   function __set($prop, $val) {
     if($prop === 'number')
       $this->_number = preg_replace('~[^0-9]~', '', $val);
   }
}

---

## #49647 — Pierre Joye — 2010-09-14T18:48:33+00:00

URL: https://externals.io/message/49645#49647 · In reply to: #49646

hi,


> 
> > […]
>
> I agree, the use cases are just not there

There are plenty of use cases for that. The main problem I see is that
nobody seems to have actually used them in other languages, and then
totally miss why it is a good thing (while not being deadly critical).
Only the syntax is discussed is somehow disturbing too.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #49648 — Ferenc Kovacs — 2010-09-14T18:49:30+00:00

URL: https://externals.io/message/49645#49648 · In reply to: #49645

> > […]
> wrote:
> > […]
> annotation
> > […]
> reasonable
> > […]
> syntax,
> > […]
> Or
> > […]
> code
> > […]
>
> I do not understand this.
>
> I see no one other than Symfony / Doctrine people pushing for this
> annotations patch.
>
> How can this special-purpose feature (which would add entirely new language
> semantics in the form of an embedded micro-language) even be open for
> discussion, when other, more generally-useful RFCs like
> http://wiki.php.net/rfc/shortsyntaxforarrays were shot down on the basis
> that they were hard to read and confusing for new developers?
>
> Sorry, but I don't see how this is even remotely close to being appropriate
> for PHP. Maybe I'm missing something. :-)
>
> Thanks,
> - Nate
>
>
It's the same as Zeev said:

"The fact we have complex components in PHP is no excuse to add more
complexity to the language.  It's not a binary state, with PHP "already
being complex", so we can add as much complexity as we want.  Complexity
accumulates."
The fact that we rejecteded better features in PHP is no excuse to reject
good ideas from the...

at least without a discussion which is just happening.

Tyrael

---

## #49649 — Stas Malyshev — 2010-09-14T19:01:41+00:00

URL: https://externals.io/message/49645#49649 · In reply to: #49647

Hi!

> There are plenty of use cases for that. The main problem I see is that
> nobody seems to have actually used them in other languages, and then

Of course not. It couldn't be that your opponents know what they are 
talking about, otherwise they'd agree with you :) Come on. Usefullness 
of annotations in Java (where they are very different, as the language 
is) or C# (which again very different from PHP) or Python (where they 
again work totally different from what is proposed) has nothing to do 
with acceptability of current implementations.
Is ability to add metadata useful? Of course. But that doesn't mean that 
any proposal implementing metadata automatically gets a pass. We'd be 
better not having it for now than having it wrong - not having can be 
fixed once a good proposal arrives, having it wrong will haunt as forever.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #49650 — Pierre Joye — 2010-09-14T19:22:55+00:00

URL: https://externals.io/message/49645#49650 · In reply to: #49649

hi Stas,



> Of course not. It couldn't be that your opponents know what they are talking
> about, otherwise they'd agree with you :) Come on. Usefullness of
> annotations in Java (where they are very different, as the language is) or
> C# (which again very different from PHP) or Python (where they again work
> totally different from what is proposed) has nothing to do with
> acceptability of current implementations.
> Is ability to add metadata useful? Of course. But that doesn't mean that any
> proposal implementing metadata automatically gets a pass.

It is an over interpretation of my reply, which was to a specific mail.

The additional comment about nobody having used annotations in other
languages (meaning having annotations experiences, not related to clue
or lack of clue) was about the proposal like using phpdoc,  arguing
about the syntax endlessly or even worst, one line reply.

That being said, I'm not proposing it and I'm relatively neutral in
here. However I am sure that PHP will gain a lot of new nice tools and
php based services if we support annotations. If this implementation
is not good enough then let us try to improve it, in the most
constructive way (that means to leave the other totally unrelated
topics behind us :).

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #49651 — Pierrick Charron — 2010-09-14T19:53:24+00:00

URL: https://externals.io/message/49645#49651 · In reply to: #49649

Hi,

Last year, I attended to a conference where you (Stas) told that the best
way to do a feature request/proposal was by writing a RFC and a patch even
if the patch is not perfect. The current implementation may not be perfect
but it was never said it was a final one. This is a proposal of a first
implementation which is a start to take people's attention and feedback.

So the first question that we have to agree is regardless the syntax, and
the entire implementation do we want to add the ability to add code metadata
(like annotations) or not into PHP. My opinion is yes. If everybody finds
this idea stupid then the discussion stops.

If we agree that Annotations are useful, then I want people who disagree on
the current implementation to say why they disagree regardless of the
current syntax (%Annotation !Annotation [Annotation] or whatever it's IMHO a
detail) and how this implementation could be improved to make it more
relevant for the PHP needs.

I can continue working on this patch if people are interested in the main
idea to improve it (I already plan to improve the patch to include Dmitry's
feedback). But I expect to get constructive feedback on how it could be
improved instead of just a discussion on why this feature is accepted and
others are not (we are not childs), or I don't like the current
implementation without any valid reason but the syntax etc.

Regards,
Pierrick

2010/9/14 Stas Malyshev <smalyshev@sugarcrm.com>

> Hi!
>
>
>  There are plenty of use cases for that. The main problem I see is that
> > […]
>
> Of course not. It couldn't be that your opponents know what they are
> talking about, otherwise they'd agree with you :) Come on. Usefullness of
> annotations in Java (where they are very different, as the language is) or
> C# (which again very different from PHP) or Python (where they again work
> totally different from what is proposed) has nothing to do with
> acceptability of current implementations.
> Is ability to add metadata useful? Of course. But that doesn't mean that
> any proposal implementing metadata automatically gets a pass. We'd be better
> not having it for now than having it wrong - not having can be fixed once a
> good proposal arrives, having it wrong will haunt as forever.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #49652 — Stas Malyshev — 2010-09-14T20:12:27+00:00

URL: https://externals.io/message/49645#49652 · In reply to: #49651

Hi!

> Last year, I attended to a conference where you (Stas) told that the
> best way to do a feature request/proposal was by writing a RFC and a
> patch even if the patch is not perfect. The current implementation may
> not be perfect but it was never said it was a final one. This is a
> proposal of a first implementation which is a start to take people's
> attention and feedback.

Of course, writing an RFC and a patch is a good way to start the process 
and I think it is great you did it. However it doesn't mean any 
RFC/patch will be accepted. That's why we discuss it - and there's no 
guarantee that the result would be acceptance. Rodin said he makes 
sculpture by chopping off extra pieces from the block of marble. We need 
to chop off stuff too sometimes if we want the language to stay easy to 
learn, read and use.

> So the first question that we have to agree is regardless the syntax,
> and the entire implementation do we want to add the ability to add code
> metadata (like annotations) or not into PHP. My opinion is yes. If
> everybody finds this idea stupid then the discussion stops.

I think we _already_ have metadata in PHP, albeit done through phpdocs. 
So the question is kind of moot :) We should see if it's enough for us 
or we want to add/change/extend it and if so, how.

I however have some doubts about usefullness of "code" metadata - i.e. 
code being run as part of metadata processing in the language. Having 
purely declarative metadata you can always have user code run on it and 
do any logic you want, but having "active" metadata seems to me to have 
high potential for complications.

Speaking of syntax, I think it is important too, because syntax defines 
readability and usability of the language. And unobvious syntax rules 
for different parts of the language hurts that.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #49653 — Pierre Joye — 2010-09-14T20:36:59+00:00

URL: https://externals.io/message/49645#49653 · In reply to: #49652

hi,



> I think we _already_ have metadata in PHP, albeit done through phpdocs. So
> the question is kind of moot :) We should see if it's enough for us or we
> want to add/change/extend it and if so, how.

I think we have the main issue here, it has absolutely nothing to do
with users documentation, as phpdoc does. Yes, they both somehow
'document' something but still totally unrelated for the goals and
usages. To understand that would help to move forward.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #49654 — Christian Kaps — 2010-09-15T05:33:13+00:00

URL: https://externals.io/message/49645#49654 · In reply to: #49652

Am 14.09.2010 22:12, schrieb Stas Malyshev:
> I think we _already_ have metadata in PHP, albeit done through
> phpdocs. So the question is kind of moot :) We should see if it's
> enough for us or we want to add/change/extend it and if so, how.
>

Hi,

in my mind there is a big mistake when using annotations in PHPDoc comments.

As example let as use a JSR 303 - Bean Validator like Hibernate
Validator for PHP.

namespace my\project\models\dto;

class User {

    /**
     * @com\jsr303\validator\constraints\NotNull
     * @com\jsr303\validator\constraints\Integer
     */
    public $id;

    /**
     * @com\jsr303\validator\constraints\NotNull
     * @com\jsr303\validator\constraints\Regexp('/[a-z]*/i')
     * @com\jsr303\validator\constraints\MinLength(2)
     * @com\jsr303\validator\constraints\MaxLength(255)
     */
    public $name;

    /**
     * @com\jsr303\validator\constraints\NotNull
     * @my\project\validator\constraints\Zipcode
     */
    public $zipcode;
}

It is possible to use this type of annotations but it is impracticable.
An other problem is that every framework use its one annotation syntax.
So it makes the framework end user more confusing as using a clear
unique syntax.

I think the PHP way should be as in the next example.

namespace my\project\models\dto;

use com\jsr303\validator\constraints\NotNull;
use com\jsr303\validator\constraints\Integer;
use com\jsr303\validator\constraints\Regexp;
use com\jsr303\validator\constraints\MinLength;
use com\jsr303\validator\constraints\MaxLength;
use my\project\validator\constraints\Zipcode;

class User {

    [NotNull]
    [Integer]
    public $id;

    [NotNull]
    [Regexp('/[a-z]*/i')]
    [MinLength(2)]
    [MaxLength(255)]
    public $name;

    [NotNull]
    [Zipcode]
    public $zipcode;
}

With this out of the box PHP annotations it makes it possible to create
powerful frameworks which can used by a great range of developers
without learning a new syntax for it. Pleas do not argue about thy
syntax of the annotation because this isn't final.

Greetings,
Christian

---

## #49655 — Stas Malyshev — 2010-09-15T06:09:02+00:00

URL: https://externals.io/message/49645#49655 · In reply to: #49654

Hi!

> class User {
>
>      [NotNull]
>      [Integer]
>      public $id;
>
>      [NotNull]
>      [Regexp('/[a-z]*/i')]
>      [MinLength(2)]
>      [MaxLength(255)]
>      public $name;
>
>      [NotNull]
>      [Zipcode]
>      public $zipcode;
> }

I'm not sure I understand - why can't you use normal data structure to 
keep this information? Why it has to be in weird syntax with []s that 
has to be accessed through reflection?

> powerful frameworks which can used by a great range of developers
> without learning a new syntax for it. Pleas do not argue about thy
> syntax of the annotation because this isn't final.

Whatever syntax it is, it is definitely new.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #49656 — Stas Malyshev — 2010-09-15T06:09:55+00:00

URL: https://externals.io/message/49645#49656 · In reply to: #49653

Hi!

> I think we have the main issue here, it has absolutely nothing to do
> with users documentation, as phpdoc does. Yes, they both somehow
 > 'document' something but still totally unrelated for the goals and
 > usages. To understand that would help to move forward.

Phpdocs aren't "user documentation" only, not for a long time (I mean 
the concept, not the particular application called phpDocumentor, of 
course). They are being used as metadata in many places. You could argue 
that's misguided but you can't ignore the fact that's what people do. 
The "goals and usages" of those tags are exactly metadata - and 
regardless of the annotations, I'd be happy if Reflection recognized it 
finally (by integrating some kind of phpdoc tag parser).

In general, I don't see why metadata written as /** @data */ is that 
much worse than metadata written as [data()]. Can you explain?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #49657 — Zeev Suraski — 2010-09-15T06:55:55+00:00

URL: https://externals.io/message/49645#49657 · In reply to: #49656

At 08:09 15/09/2010, Stas Malyshev wrote:
>Phpdocs aren't "user documentation" only, not for a long time (I 
>mean the concept, not the particular application called 
>phpDocumentor, of course). They are being used as metadata in many 
>places. You could argue that's misguided but you can't ignore the 
>fact that's what people do. The "goals and usages" of those tags are 
>exactly metadata - and regardless of the annotations, I'd be happy 
>if Reflection recognized it finally (by integrating some kind of 
>phpdoc tag parser).

I second that word for word.  FWIW, I don't see it as misguided at all.

Zeev

---

## #49663 — Benjamin Eberlei — 2010-09-15T08:45:37+00:00

URL: https://externals.io/message/49645#49663 · In reply to: #49657

Hi Zeev and Stas,

I wouldnt mind extending doc block metadata support instead of adding a
new syntax.

I agree with you that PHP Docs allow metadata and they can be used for
that (and some people do, including me), however what the annotation patch
+ rfc tries to achieve is something going beyong $refl->getDocComment()
returning a string only. The string only return leads to hunderets of
different approaches for annotating metadata in all the different
frameworks and libraries. A single unified syntax would be benefitial.

That is why I don't know if it will even be possible to extend the doc
blocks in a generic way that does not break half the applications out
there.

When extending doc-blocks there is probably new method required
$refl->getParsedDocComment() which then returns an array of metadata for
that particular refl instance. Now here the syntax would be a problem, can
we find something that does not break for all the different usages of
docblocks out there? Since the method/parsing would be nested, on request
only it wouldnt break any application that does not use parsed doc
comments. However for applications that do, a syntax needs to be found
that:

1. does not break for various type hinting doc syntaxes
2. does not break for various commenting styles

Can someone come up with additional pitfalls?

greetings,
Benjamin



    At 08:09 15/09/2010, Stas Malyshev wrote:

        Phpdocs aren't "user documentation" only, not for a long time (I
mean the concept, not the particular application called phpDocumentor, of
course). They are being used as metadata in many places. You could argue
that's misguided but you can't ignore the fact that's what people do. The
"goals and usages" of those tags are exactly metadata - and regardless of
the annotations, I'd be happy if Reflection recognized it finally (by
integrating some kind of phpdoc tag parser). 

    I second that word for word. FWIW, I don't see it as misguided at all.
Zeev

---

## #49667 — Lars Schultz — 2010-09-15T09:45:57+00:00

URL: https://externals.io/message/49645#49667 · In reply to: #49663

listen to this man;) I think he's on to something. I don't see any 
problem with that aproach and both parties would be satisfied, no?

Am 15.09.2010 10:45, schrieb Benjamin Eberlei:
>
> Hi Zeev and Stas,
>
>
>
> I wouldnt mind extending doc block metadata support instead of adding a
>
> new syntax.
>
>
>
> I agree with you that PHP Docs allow metadata and they can be used for
>
> that (and some people do, including me), however what the annotation patch
>
> + rfc tries to achieve is something going beyong $refl->getDocComment()
>
> returning a string only. The string only return leads to hunderets of
>
> different approaches for annotating metadata in all the different
>
> frameworks and libraries. A single unified syntax would be benefitial.
>
>
>
> That is why I don't know if it will even be possible to extend the doc
>
> blocks in a generic way that does not break half the applications out
>
> there.
>
>
>
> When extending doc-blocks there is probably new method required
>
> $refl->getParsedDocComment() which then returns an array of metadata for
>
> that particular refl instance. Now here the syntax would be a problem, can
>
> we find something that does not break for all the different usages of
>
> docblocks out there? Since the method/parsing would be nested, on request
>
> only it wouldnt break any application that does not use parsed doc
>
> comments. However for applications that do, a syntax needs to be found
>
> that:
>
>
>
> 1. does not break for various type hinting doc syntaxes
>
> 2. does not break for various commenting styles
>
>
>
> Can someone come up with additional pitfalls?
>
>
>
> greetings,
>
> Benjamin
>
>
>
> 
>
>
>
>      At 08:09 15/09/2010, Stas Malyshev wrote:
>
>
>
>          Phpdocs aren't "user documentation" only, not for a long time (I
>
> mean the concept, not the particular application called phpDocumentor, of
>
> course). They are being used as metadata in many places. You could argue
>
> that's misguided but you can't ignore the fact that's what people do. The
>
> "goals and usages" of those tags are exactly metadata - and regardless of
>
> the annotations, I'd be happy if Reflection recognized it finally (by
>
> integrating some kind of phpdoc tag parser).
>
>
>
>      I second that word for word. FWIW, I don't see it as misguided at all.
>
> Zeev

---

## #49668 — Guilherme Blanco — 2010-09-15T16:17:49+00:00

URL: https://externals.io/message/49645#49668 · In reply to: #49667

It's curious that you keep complaining about new syntax and propose a
new one at the same time.

[Foo] introduces new concept, use /** @Foo */  or /** [Foo] */ instead.
What's the point then?

I think meta programming is not and would never be part of comment.
As previously said, docblock means documentation, without any meaning
to parser, entirely human readable and totally removable without
affecting overall execution.
Something that HAS a meaning to execution means something out of the
userland comments. Point made.

Cheers,


> listen to this man;) I think he's on to something. I don't see any problem
> with that aproach and both parties would be satisfied, no?
>
> Am 15.09.2010 10:45, schrieb Benjamin Eberlei:
> > […]
>
>
> --
> 
> 
>
>



-- 
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

---

## #49674 — Gustavo Lopes — 2010-09-15T19:24:08+00:00

URL: https://externals.io/message/49645#49674 · In reply to: #49657

> At 08:09 15/09/2010, Stas Malyshev wrote:
> > […]
>
> I second that word for word.  FWIW, I don't see it as misguided at all.
>

OK, here's why "doc comments" are insufficient:

1. You have to manually parse them (which is not easy; writing parsers is  
quite error prone). You would also probably need to implement some form of  
annotation inheritance.
2. There's no standardized way to express annotations, so the user will  
have to learn a new syntax for each implementation.
3. Performance issues -- you to have to parse and validate the annotations  
on each request, unless you implement your own caching mechanism. With  
native annotations, you could use opcode caches to do parsing and  
validation only on the first request.
4. Finally, and this is the most significant to me -- since PHP doesn't  
know annotations (it only knows there's a blob a text), you cannot give to  
certain annotations a meaning that would be recognized at an engine. With  
annotations, we could, in the future, implement a special meaning for  
@ReadOnly and @WriteOnly for properties and have stuff like:

@RunBefore("Log::writeMessage")
public LogAnnotation extends ReflectionAnnotation {
	public $value;
}
...

@Log("Enterting method Foo::bar")
@RequiredRole("moderator")
public function bar() { }

without having to run the method through a framework that would recognize  
those annotations in doc blocks. However, the only thing close to this in  
the current implementation is @Inherited.


Finally, a separate issue is the syntactic one. Could we use the current  
implementation but define the annotations in doc blocks instead?

If it comes to that, it'd be better than nothing. However, It would almost  
certainly break BC (and subjectively, it feels wrong to mix annotations,  
which have real impact on the application, with mere comments).

If the annotations were parsed only on request, it would not break BC in  
the sense that whole old applications would stop working; however, when  
upgrading PHP and the framework to a new version that would support  
annotations, it could misinterpret old doc comments that look like  
annotations (or most likely, malformed annotations). More importantly, it  
would break a compelling reason to have annotations (point 4.).


-- 
Gustavo Lopes

---

## #49676 — Jonathan Bond-Caron — 2010-09-15T20:04:58+00:00

URL: https://externals.io/message/49645#49676 · In reply to: #49668

> I think meta programming is not and would never be part of comment.
> As previously said, docblock means documentation, without any meaning 
> to parser, entirely human readable and totally removable without 
> affecting overall execution.

I have to agree here, there's lots of php tools that 'strip comments'.

If you strip comments, you'd be effectively removing 'annotations' which changes how that code would run in a given framework or tool. It kind of defeats the purpose.

But my opinion as an end user and framework developer:

the rfc really needs to elaborate on the use cases *specific to php*

java has some here: 
http://jcp.org/en/jsr/detail?id=250

Does php need to be become this complicated?

I worry about how php can grow complicated to a point where you won't be able to use it without using tool or framework X.
I'll use .NET, thank you very much.

---

## #49677 — Arvids Godjuks — 2010-09-15T20:27:24+00:00

URL: https://externals.io/message/49645#49677 · In reply to: #49676

Hi all.

As a user land developer and active reader (and some times poster) for
a few years now this is the first time I trully don't understand what
the hell are you talking about and what are annotations at all and
what will be the usage of them in the PHP. And for what? Building 2-3
frameworks and that's all (as I understand from reading this
discussion)?

I'm sure pretty much user land developers read this thread and ask
themselves the same question.

P.S. Personally I would take the energy boiling in this thread and
throw it at solving the windows biuld and PECL problem. Right now you
can't install PHP 5.2 and apache on a Windows 7 - it just crashes
totally. Only 5.3 works, not to mention much of the PECL libs just
don't have dll's (lucky if you find one in the Google). The same goes
for the PECL dll's for 5.3 - all of them, excluding the standard once,
mostly are missing and can't be found at all.

---

## #49689 — Ferenc Kovacs — 2010-09-16T08:05:34+00:00

URL: https://externals.io/message/49645#49689 · In reply to: #49677

On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
<arvids.godjuks@gmail.com>wrote:

> Hi all.
>
> As a user land developer and active reader (and some times poster) for
> a few years now this is the first time I trully don't understand what
> the hell are you talking about and what are annotations at all and
> what will be the usage of them in the PHP. And for what? Building 2-3
> frameworks and that's all (as I understand from reading this
> discussion)?
>
>
Did you read the quoted references in this thread?
It's a new feature proposal as for example closures or traits, if you don't
know what are they, you have to do some work to understand them, but thats
all.
You should understand the discussion, before choosing your side.


> I'm sure pretty much user land developers read this thread and ask
> themselves the same question.
>

dunno, I'm a user land developer, and I don't ask the same question, so it's
1:1 for now.


>
> P.S. Personally I would take the energy boiling in this thread and
> throw it at solving the windows biuld and PECL problem. Right now you
> can't install PHP 5.2 and apache on a Windows 7 - it just crashes
> totally. Only 5.3 works, not to mention much of the PECL libs just
> don't have dll's (lucky if you find one in the Google). The same goes
> for the PECL dll's for 5.3 - all of them, excluding the standard once,
> mostly are missing and can't be found at all.
>

party agree here, feel free to open a new thread or issue, but one problem
doesn't mean, that we can't discuss other ideas, until that problem is
fixed.

Tyrael

---

## #49692 — Pierre Joye — 2010-09-16T08:21:08+00:00

URL: https://externals.io/message/49645#49692 · In reply to: #49677

On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
<arvids.godjuks@gmail.com> wrote:

> P.S. Personally I would take the energy boiling in this thread and
> throw it at solving the windows biuld and PECL problem. Right now you
> can't install PHP 5.2 and apache on a Windows 7 - it just crashes
> totally.

Where are the bugs report?

> Only 5.3 works, not to mention much of the PECL libs just
> don't have dll's (lucky if you find one in the Google). The same goes
> for the PECL dll's for 5.3 - all of them, excluding the standard once,
> mostly are missing and can't be found at all.

What are you talking about? Not a real question, use bugs.php.net for
php extensions, if something is broken or missing.

Thanks to focus on the topic and not hi jack this thread with random rants.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #49693 — Aleksei Sapunov — 2010-09-16T08:26:51+00:00

URL: https://externals.io/message/49645#49693 · In reply to: #49692

Hello all,
Only today see that here is very intersting discussion.
I have a question: why was choosed exactly this format (seems like c#-like,
not java-like)?
Simply [] is used for arrays. Why not use @ at annotation name?

2010/9/16 Pierre Joye <pierre.php@gmail.com>

> On Wed, Sep 15, 2010 at 10:27 PM, Arvids Godjuks
> <arvids.godjuks@gmail.com> wrote:
>
> > […]
>
> Where are the bugs report?
>
> > […]
>
> What are you talking about? Not a real question, use bugs.php.net for
> php extensions, if something is broken or missing.
>
> Thanks to focus on the topic and not hi jack this thread with random rants.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #49694 — Christian Kaps — 2010-09-16T08:32:19+00:00

URL: https://externals.io/message/49645#49694 · In reply to: #49693

Hi,

it's reserved for the error control
operator(http://www.php.net/manual/en/language.operators.errorcontrol.php).

Greetings,
Christian

On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov <saprizo@gmail.com>
wrote:
> Hello all,
> Only today see that here is very intersting discussion.
> I have a question: why was choosed exactly this format (seems like c#-like,
> not java-like)?
> Simply [] is used for arrays. Why not use @ at annotation name?
> 
> 2010/9/16 Pierre Joye <pierre.php@gmail.com>
> 
> > […]

---

## #49696 — Aleksei Sapunov — 2010-09-16T08:40:16+00:00

URL: https://externals.io/message/49645#49696 · In reply to: #49694

Hi,
Yes, you right. But [] are used in arrays definition. If take in to account
that format with @ is more readable?

Is it a problem to implement it using @ symbol?

2010/9/16 Christian Kaps <christian.kaps@mohiva.com>

> Hi,
>
> it's reserved for the error control
> operator(http://www.php.net/manual/en/language.operators.errorcontrol.php
> ).
>
> Greetings,
> Christian
>
> On Thu, 16 Sep 2010 11:26:51 +0300, Aleksei Sapunov <saprizo@gmail.com>
> wrote:
> > […]
> c#-like,
> > […]
> rants.
> > […]

---

## #49697 — Adam Harvey — 2010-09-16T08:43:39+00:00

URL: https://externals.io/message/49645#49697 · In reply to: #49696

> Hi,
> Yes, you right. But [] are used in arrays definition. If take in to account
> that format with @ is more readable?
>
> Is it a problem to implement it using @ symbol?

If we're down to bickering about the finer points of the syntax, can
we just have a vote already? Please?

Adam

---

Next page: https://externals.io/message/49645.md?page=2