Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <4C8D2214.2030904@sugarcrm.com>
Date: Sun, 12 Sep 2010 11:55:16 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Christian Kaps <christian.kaps@mohiva.com>
CC: Pierre Joye <pierre.php@gmail.com>, 
 Guilherme Blanco <guilhermeblanco@gmail.com>,
 Pierrick Charron <pierrick@webstart.fr>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <AANLkTimuWDV=9AA63_9M6cQSp9riCPE214sUNdoV3tQn@mail.gmail.com>	<4C873C0F.1010200@zend.com>	<AANLkTimdCnW3ABq5QSnBa78H14e2LPBa=Kt2txU0sTD4@mail.gmail.com>	<4C879613.7090709@zend.com>	<AANLkTim-dHYyJxX2R3-PBVqqa3sv3+zKYr7zw7QvyngJ@mail.gmail.com>	<4C887D2B.2000605@zend.com>	<4C8AC526.7000505@sugarcrm.com>	<AANLkTikpCGj2zVNQmC1gUWaRSpsQD=qNrETi90wj_No7@mail.gmail.com>	<4C8B6168.30504@mohiva.com>	<AANLkTinuD_Aga-CbsbSq-23MTyOLPGrBEswTm=JtBY0H@mail.gmail.com>	<4C8BC81E.8000605@sugarcrm.com> <AANLkTinFSqCFUE3P5XvjJPwUGZqYrQR_9VHAXAWSL=rv@mail.gmail.com> <4C8C073F.402@sugarcrm.com> <4C8C8FBC.3090007@mohiva.com>
In-Reply-To: <4C8C8FBC.3090007@mohiva.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP Annotations RFC + Patch
From: smalyshev@sugarcrm.com (Stas Malyshev)

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, annotation can't be interface since you'd have to instantiate it 
to get the values. Interface can't have values.

> is to create a new "annotation" type. This type should have the same
> rules as a class and should contain all features proposed in the
> ReflectionAnnotation class. With this construct it should be possible to
> use named or unnamed parameters for an annotation.

I think this is very bad idea - to have language construct that is 
exactly like class but has different set of features. If named 
parameters are needed in PHP, let's add named parameters in PHP. But if 
we decide they are not needed in PHP, they shouldn't be in one 
particular corner of a particular syntax construct and nowhere else. 
This makes the language hard to learn and hard to understand - you never 
know what surprise the next syntax construct will bring you. I'm very 
strongly against only one construct in the language having named 
parameters syntax while other places don't.

> 2. The syntax for arrays should be the same as in PHP. So we can use the
> [] as annotation separator. When we allow expressions in the form
> Annotation(array('value' =>  4 %2)) or Annotation(array('value' =>
> !MY_CONSTANT)) which I think is a valid construct, then we cannot use
> the ! or % as annotation separator.

Where this expression would be evaluated, in which context? Where would 
the variable values be stored? What happens if they change?

> I think with this changes we have a separate language construct like
> traits, which does allow a new syntax.

Separate language construct doesn't mean separate rules. We are still in 
the same language, so we can't just randomly put arbitrary set of 
features together and call it a new construct. There should be some 
commonality between different language constructs within the same language.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227