To me it's simply as that:
class_statement:
variable_modifiers optional_type property_list ';' { $$ = $2;
$$->attr = $1 }
| ...
property_list:
property_list ',' property { $$ = zend_ast_list_add($1, $3); }
| property { $$ = zend_ast_create_list(1, ZEND_AST_PROP_DECL, $1); }
;
I think this makes the concept more palatable compared to others and other
languages (single type declaration per statement).
Regards,
On Thu, Mar 31, 2016 at 12:19 PM, Larry Garfield <la...@garfieldtech.com>
wrote:
> On 3/31/16 8:01 AM, Zeev Suraski wrote:
>
>>
>> -----Original Message-----
>>> From: Joe Watkins [mailto:pthre...@pthreads.org]
>>> Sent: Thursday, March 31, 2016 3:41 PM
>>> To: Dmitry Stogov <dmi...@zend.com>
>>> Cc: Björn Larsson <bjorn.x.lars...@telia.com>; Phil Sturgeon
>>> <pjsturg...@gmail.com>; Krakjo <krak...@php.net>; PHP internals
>>> <internals@lists.php.net>
>>> Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
>>>
>>> Morning Dmitry,
>>>
>>> This should be a error. I also think, that "public" might be omitted,
>>>> and it should be possible to write "int $bar, $foo"
>>>>
>>> Omitting public might be nice, but also totally separate, you should be
>>> able to
>>> omit it for untyped properties too.
>>>
>>> You say - C, C++, Java, HHVM, etc - all made worse decision? OK
>>>>
>>> No. C, C++, C#, and Java had a different decision to make.
>>>
>> I don't think the decision is fundamentally different. It's
>> fundamentally very similar if not identical.
>>
>> [public] int foo, bar;
>>>
>>> It is obvious that bar is an int in any of those languages precisely
>>> because it
>>> necessarily has a type.
>>>
>>> Why we should jump to the same conclusion, in a system where properties
>>> do
>>> not necessarily have types is not clear to me.
>>>
>> Because we're dealing with a single statement, and we already have the
>> concept that a modifier for that statement is enforced throughout the
>> statement - I don't see how whether that modifier is mandatory or not makes
>> any meaningful difference. Having an access modifier affect the entire
>> statement, while a type modifier affecting only the variable next to it -
>> is extremely inconsistent.
>>
>> If
>>
>> Private Person $p, Car $c;
>>
>> works, why shouldn't:
>> Private Person $p, public Car $c;
>>
>> Work as well?
>>
>> In addition to being inconsistent, it also calls for poor coding
>> practices - mixing typed and untyped declarations in a single statement -
>> as well as different types in a single declaration. In that context, what
>> drove other languages to pick their syntax and force developers to separate
>> declaration of different variables types into different statements -
>> applies exactly in the same manner for all other languages, us included.
>>
>> Zeev
>>
>
> Honestly I never even realized that you could put multiple declarations on
> a single line, have never done so, and would reject code from any of my
> projects that did so as poor style. :-) That said, since it is legal I
> agree that it should be kept unambiguous and consistent.
>
> From what Zeev is saying, the following seems like a reasonable rule: You
> get ONE visibility modifier and ONE type statement per declaration, and
> both must come at the beginning, period. That is, the following are legal:
>
> public int $a, $b;
> protected $a, $b;
> var int $a, $b;
>
> And always apply across the entire line, period.
>
> The following are all syntax errors:
>
> public int $a, string $b;
> var int $a, protected $b;
> private $a, float $b;
>
> That seems fairly easy for a reader to follow, reasonably consistent, and
> I presume straightforward to implement (not being a C developer I hand-wave
> that part...). If you want to do something more complex... make it
> multiple statements. That's why multiple statements exist.
>
> Zeev, is that an accurate summary of what you're arguing?
>
> --
> --Larry Garfield
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
