Re: [PHP-DEV] Final version, RFC release process

[Peter Lind]

On Jun 2, 2011 12:46 AM, "Pierre Joye"  wrote:
>
> hi Chris
>
> On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
>  wrote:
> >
> >
> > On 06/01/2011 03:09 AM, Pierre Joye wrote:
> >
> >> URL: https://wiki.php.net/rfc/releaseprocess
> >
> > Pierre,
> >
> > There are some immediately practical things here.  Some things will
> > be a large jolt for the community and might be better introduced in
> > future releases.
> >
> > Chris
> >
> > Good:
> >  - Scheduled releases
> >  - Use of RFCs
> >  - No PHP script breakages in x.y.z+1 releases
> >
> > Too complex or not good:
> >  - Number of concurrent branches: Johannes's suggestion was good
>
> This proposal for distros not for programming languages or similar
> tools. All users I talk to need fixed timeline, life cycle, etc. to
> have a clear and plan-able way to deal with php versions.
>

Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are fixed
timelines and life cycles in Ubuntu - having less branches does not in any
way stop them from having a fixed release process and schedule.

Regards
Peter

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Sanford Whiteman]

> I don't think anyone cares about JSON for the sake of being perfect
> JSON, I didn't intend to give that impression.

Then you should stop saying "pure JSON" and "true JSON" constantly!

> I'm  only  hoping for something that generally works on par with all
> the  other  JSON parsers in the world.

OK,  that  trashes  your  example,  where values were set based on the
result  of  a PHP function. There is no "par" for JSON parsers running
methods  _at  creation  time_,  within  the  server  (author) context.
Setting  vars  to  the return value of a function is something we take
for  granted  in  real  languages,  but it cannot happen within what a
knowledgeable person would call "JSON."

> Yes,  JSON  is a very specific encoding, but when a developer writes
> something  "jsony",  what  they  mean  is  "an object/array with the
> following  structure/values",  because  that  is  what  the encoding
> really represents.

Not Javascript developers. Maybe jQiddies think that

{'$gt': strtotime('-1 day')}

is "JSONy" more than it is "JS objecty"?

This is like starting from "Wouldn't inline CSVs be great for creating
arrays?"  and  drifting  to "I mean, not like with that comma-escaping
stuff,  and,  uh, newlines would be allowed in the middle of a record,
and  you'd  have to allow create-time interpolation of function calls.
You know, CSVy!"

Only  thing  I  might  generously  refer  to  as  being "JSONy," while
provably  not being valid JSON, is a string that conforms in every way
_except_  for  using  single  quotes  --  everywhere  that doubles are
required  --  instead  of  using  doubles.  Anything else is someone's
mangled "JankySON" or just not JSON.

-- S.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[David Zülke]

On 02.06.2011, at 00:53, Marcel Esser wrote:

> Hrm. It seems to me that it's not just Mongo that has chosen that as a
> query definition language. A fair number of other projects have, too. If
> not as a query language, then related things.

It's the worst idea of this decade, and just because others have repeated it, 
it's not automatically a good one. {foo: 1, bar: 1} works fine, so they 
implemented that, and then they realized that they had to do ORs as well, so 
they invented $or and a whole bunch of other "workarounds".


> As for decoding Unicode, well, json_decode seems to do a pretty good job.
> And if I am not mistaken, they are always in quotation marks, so it
> shouldn't really be such a terrible issue to delimit as such. I am not
> certain about that, but, again, json_decode seems to manage.

json_decode() decodes to UTF-8.

What if I do this, in a latin1 encoded file:

$x = {foo: "ä", bar: "\u0123"}

Should that then give mixed encodings? The "ä" in foo in latin1 and the stuff 
in bar in UTF-8?

And what if I do:

$x = {foo: "ä\u0123"}

I'll either end up with an invalid UTF-8 sequence, or with latin1 character 
soup.

David


 

> 
> - M.
> 
> -- 
> Marcel Esser
> 
> Vice President of Engineering, CROSCON
> +1 (202) 470-6090
> marcel.es...@croscon.com
> 
> Before printing this e-mail, please consider the rainforest.
> 
> 
> 
> 
> On 6/1/11 6:47 PM, "David Zülke"  wrote:
> 
>> Just because the MongoDB developers were stupid enough to build a query
>> language on top of JSON does not mean that JSON or JavaScript object
>> literals need to be supported in PHP. And it wouldn't be possible anyway
>> since JSON allows Unicode escape sequences, and PHP cannot even represent
>> those as it is not aware of runtime encodings.
>> 
>> Besides, outside the use case of json_decode(), stdClass is rarely ever
>> useful, so I don't understand why we're even discussing {} shorthands
>> here. It's not in the RFC either, so good job on focusing on the issue
>> and not diluting the discussion.
>> 
>> Getting back to the RFC: I think it's problematic to have two separate
>> syntaxes for the key/value separator. For consistency's sake, I'd rather
>> just have "=>" but not ":". Just my $0.02.
>> 
>> David
>> 
>> 
>> On 02.06.2011, at 00:09, John Crenshaw wrote:
>> 
>>> For small linear arrays, neither format is "more readable" but for even
>>> mildly complex structures, there is a clear difference. Consider the
>>> following Mongo query:
>>> 
>>> $query = array(
>>>   'time'=>array('$and'=>array(
>>>   array('$gt'=>strtotime('-1 day')),
>>>   array('$lt'=>time()),
>>>   )),
>>>   '$or'=>array(
>>>   array('foo'=>'bar'),
>>>   array('hello'=>'world')
>>>   )
>>> );
>>> 
>>> Vs. the JSON form:
>>> $query = {
>>>   time: {'$and': [
>>>   {'$gt': strtotime('-1 day')},
>>>   {'$lt': time()},
>>>   ]},
>>>   '$or': [
>>>   {foo: 'bar'},
>>>   {hello: 'world'}
>>>   ]
>>> };
>>> 
>>> Because of the clear readability difference I'll take anything, but
>>> JSON would be much better than just an "array shorthand".
>>> 
>>> John Crenshaw
>>> Priacta, Inc.
>>> 
>>> -Original Message-
>>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>>> Sent: Wednesday, June 01, 2011 5:18 PM
>>> To: PHP internals
>>> Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>>> 
>>> Personally, I think focusing on a character savings is the wrong
>>> reason to take on any problem.  I don't care how long it takes for me
>>> to type code.  I don't care how much extra hdd space it takes.  But
>>> what I do care about is how readable it is.
>>> 
>>> To me, the array shortcut syntax is pointless.  Do you really mean to
>>> tell me that `[1, 2]` is more readable/easier to understand than
>>> `array(1,2)`?  To me, it's about a wash.
>>> 
>>> However, the object shortcut syntax is a major win.  For example:
>>> 
>>> $person = new stdClass();
>>> $person->city = 'ogden';
>>> $person->state = 'ut';
>>> $perspn->country = 'usa';
>>> $person->favoriteNumbers = array(4, 12, 37, 42);
>>> $person->somethingWithNumbers();
>>> $person->unluckyNumbers = array(6, 13, 21);
>>> $person->likesPhp = 'very much so';
>>> 
>>> vs
>>> 
>>> $person =  { 'name' => 'Justin',
>>>  'city' => 'ogden',
>>>  'state' => 'ut',
>>>  'country' => 'usa',
>>>  'favoriteNumbers' => [ 4, 12, 37, 42],
>>>  'unluckyNumbers' => [ 6, 13, 21],
>>>  'likesPhp' => 'very much so'
>>> }
>>> 
>>> Did you notice what happened there?  There's two differences.  Try to
>>> find them.  Neither would be possible with the shortcut syntax.
>>> 
>>> Now, the only reason I would personally support the array shortcut is
>>> if it was an implementation of JSON.  I know that's not on the table
>>> here, but that's the only benefit I can see to implementing a shortcut
>>> for arrays (that would save 5 characters per instance).
>>> 
>>> Just my $0.02...
>>> 
>>> Anthony
>>> 
>>> On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony
>>>  wrote:
 To address the soapbo

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Matt Wilson]

The issue I have with that is that, regardless of the syntax chosen, even if it 
meant a 100% inline JSON syntax, you would still (for obvious reasons) need to 
parse any JSON string into PHP structures. You still have to do 
json_load($php_or_json_string) or (god have mercy) eval($string). At that 
point, the only convenience you get from having JSON syntax in php is the 
situational ability to copy a JSON string directly into your source code. 

I just don't think that's worth introducing a new kind of array/object syntax 
into PHP. I might prefer that syntax (like python) but I don't think it's right 
for this language.

On Jun 1, 2011, at 6:28 PM, John Crenshaw wrote:

> I don't think anyone cares about JSON for the sake of being perfect JSON, I 
> didn't intend to give that impression. I'm only hoping for something that 
> generally works on par with all the other JSON parsers in the world. In other 
> words something with roughly the same syntax, constraints, and flexibility as 
> the average browser based JavaScript implementation. Making JSON some special 
> totally separate object type would totally miss the point and meaning of any 
> developer writing such code. Yes, JSON is a very specific encoding, but when 
> a developer writes something "jsony", what they mean is "an object/array with 
> the following structure/values", because that is what the encoding really 
> represents.
> 
> John Crenshaw
> Priacta, Inc.
> 
> -Original Message-
> From: dukeofgaming [mailto:dukeofgam...@gmail.com] 
> Sent: Wednesday, June 01, 2011 6:52 PM
> To: Michael Shadle
> Cc: Sean Coates; Anthony Ferrara; PHP internals
> Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
> 
> I still don't get it, the idea of making it look like json wont make it
> json, it will be PHP, and if you dare to write you "jsony" object/array with
> single quoted strings wont break the code even when its not JSON.
> 
> I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
> even more times:
> 
> Not even Javascript supports 100% valid JSON
> Not even Javascript supports 100% valid JSON
> Not even Javascript supports 100% valid JSON
> Not even Javascript supports 100% valid JSON
> Not even Javascript supports 100% valid JSON
> 
> JSON even has its own mime type. The idea of JSON as a first-class citizen
> is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
> put it in a separate RFC and lets decide con the actual RFC. Perhaps the
> JSON idea could benefit from autoboxing and a native class?:
> https://wiki.php.net/rfc/autoboxing
> 
> JSON is a serializarion format, not a data structure, you coud write an
> associative array and if PHP knew the way, it could be autointerpreted as
> JSON, no need to make PHP code look like JSON. I think that the *BEHAVIOR*
> of arrays/objects as JSON and without the intervention of serialization
> functions should be in a separate RFC. There is really no point to make PHP
> *look* like JSON to handle JSON natively .
> 
> This JSON matter and short array/object syntax are different issues just the
> way " 
> Could someone get Douglas Crockford in here?, rofl.
> 
> Regards,
> 
> David
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[John Crenshaw]

I don't think anyone cares about JSON for the sake of being perfect JSON, I 
didn't intend to give that impression. I'm only hoping for something that 
generally works on par with all the other JSON parsers in the world. In other 
words something with roughly the same syntax, constraints, and flexibility as 
the average browser based JavaScript implementation. Making JSON some special 
totally separate object type would totally miss the point and meaning of any 
developer writing such code. Yes, JSON is a very specific encoding, but when a 
developer writes something "jsony", what they mean is "an object/array with the 
following structure/values", because that is what the encoding really 
represents.

John Crenshaw
Priacta, Inc.

-Original Message-
From: dukeofgaming [mailto:dukeofgam...@gmail.com] 
Sent: Wednesday, June 01, 2011 6:52 PM
To: Michael Shadle
Cc: Sean Coates; Anthony Ferrara; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you "jsony" object/array with
single quoted strings wont break the code even when its not JSON.

I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even more times:

Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON

JSON even has its own mime type. The idea of JSON as a first-class citizen
is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
put it in a separate RFC and lets decide con the actual RFC. Perhaps the
JSON idea could benefit from autoboxing and a native class?:
https://wiki.php.net/rfc/autoboxing

JSON is a serializarion format, not a data structure, you coud write an
associative array and if PHP knew the way, it could be autointerpreted as
JSON, no need to make PHP code look like JSON. I think that the *BEHAVIOR*
 of arrays/objects as JSON and without the intervention of serialization
functions should be in a separate RFC. There is really no point to make PHP
*look* like JSON to handle JSON natively .

This JSON matter and short array/object syntax are different issues just the
way "http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Marcel Esser]

Hrm. It seems to me that it's not just Mongo that has chosen that as a
query definition language. A fair number of other projects have, too. If
not as a query language, then related things.

As for decoding Unicode, well, json_decode seems to do a pretty good job.
And if I am not mistaken, they are always in quotation marks, so it
shouldn't really be such a terrible issue to delimit as such. I am not
certain about that, but, again, json_decode seems to manage.

- M.

-- 
Marcel Esser

Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com

Before printing this e-mail, please consider the rainforest.




On 6/1/11 6:47 PM, "David Zülke"  wrote:

>Just because the MongoDB developers were stupid enough to build a query
>language on top of JSON does not mean that JSON or JavaScript object
>literals need to be supported in PHP. And it wouldn't be possible anyway
>since JSON allows Unicode escape sequences, and PHP cannot even represent
>those as it is not aware of runtime encodings.
>
>Besides, outside the use case of json_decode(), stdClass is rarely ever
>useful, so I don't understand why we're even discussing {} shorthands
>here. It's not in the RFC either, so good job on focusing on the issue
>and not diluting the discussion.
>
>Getting back to the RFC: I think it's problematic to have two separate
>syntaxes for the key/value separator. For consistency's sake, I'd rather
>just have "=>" but not ":". Just my $0.02.
>
>David
>
>
>On 02.06.2011, at 00:09, John Crenshaw wrote:
>
>> For small linear arrays, neither format is "more readable" but for even
>>mildly complex structures, there is a clear difference. Consider the
>>following Mongo query:
>> 
>> $query = array(
>>'time'=>array('$and'=>array(
>>array('$gt'=>strtotime('-1 day')),
>>array('$lt'=>time()),
>>)),
>>'$or'=>array(
>>array('foo'=>'bar'),
>>array('hello'=>'world')
>>)
>> );
>> 
>> Vs. the JSON form:
>> $query = {
>>time: {'$and': [
>>{'$gt': strtotime('-1 day')},
>>{'$lt': time()},
>>]},
>>'$or': [
>>{foo: 'bar'},
>>{hello: 'world'}
>>]
>> };
>> 
>> Because of the clear readability difference I'll take anything, but
>>JSON would be much better than just an "array shorthand".
>> 
>> John Crenshaw
>> Priacta, Inc.
>> 
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Wednesday, June 01, 2011 5:18 PM
>> To: PHP internals
>> Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>> 
>> Personally, I think focusing on a character savings is the wrong
>> reason to take on any problem.  I don't care how long it takes for me
>> to type code.  I don't care how much extra hdd space it takes.  But
>> what I do care about is how readable it is.
>> 
>> To me, the array shortcut syntax is pointless.  Do you really mean to
>> tell me that `[1, 2]` is more readable/easier to understand than
>> `array(1,2)`?  To me, it's about a wash.
>> 
>> However, the object shortcut syntax is a major win.  For example:
>> 
>> $person = new stdClass();
>> $person->city = 'ogden';
>> $person->state = 'ut';
>> $perspn->country = 'usa';
>> $person->favoriteNumbers = array(4, 12, 37, 42);
>> $person->somethingWithNumbers();
>> $person->unluckyNumbers = array(6, 13, 21);
>> $person->likesPhp = 'very much so';
>> 
>> vs
>> 
>> $person =  { 'name' => 'Justin',
>>   'city' => 'ogden',
>>   'state' => 'ut',
>>   'country' => 'usa',
>>   'favoriteNumbers' => [ 4, 12, 37, 42],
>>   'unluckyNumbers' => [ 6, 13, 21],
>>   'likesPhp' => 'very much so'
>> }
>> 
>> Did you notice what happened there?  There's two differences.  Try to
>> find them.  Neither would be possible with the shortcut syntax.
>> 
>> Now, the only reason I would personally support the array shortcut is
>> if it was an implementation of JSON.  I know that's not on the table
>> here, but that's the only benefit I can see to implementing a shortcut
>> for arrays (that would save 5 characters per instance).
>> 
>> Just my $0.02...
>> 
>> Anthony
>> 
>> On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony
>> wrote:
>>> To address the soapbox:
>>> 
>>> Its not just to reduce the five characters at the beginning, but when
>>>you have more complex structures as well. There was already a great
>>>example shown 
>>>(http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html)
>>>of that. Also, if object support is added (which we need to add to the
>>>RFC), you can cut down on a lot more verbose code, especially with
>>>objects.
>>> 
>>> $person = { 'name' => 'Justin',
>>>'city' => 'ogden',
>>>'state' => 'ut',
>>>'country' => 'usa',
>>>'favoriteNumbers' => [ 4, 12, 37, 42],
>>>'unluckyNumbers' => [ 6, 13, 21],
>>>'likesPhp' => 'very much so'
>>> };
>>> 
>>> Characters: 192
>>> 
>>> Current way:
>>> 
>>> $person = new stdClass();
>>> $person->city = 'ogden';
>>> $person->state = 'ut';
>>> $person->country = 'usa';
>>> $person->favoriteN

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

hi David,

On Thu, Jun 2, 2011 at 12:47 AM, David Zülke
 wrote:
> Just because the MongoDB developers were stupid enough to build a query 
> language on top of JSON

Many of us know that you have a deep and constant hate for MongoDB.
However please do respect the netiquette and every developers here. An
idea may be stupid, not necessary developers. While the idea of a
binary format to transfer data is a good idea, in general.

Thanks for your understanding,

Cheers,
-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[dukeofgaming]

I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you "jsony" object/array with
single quoted strings wont break the code even when its not JSON.

I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even more times:

Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON
Not even Javascript supports 100% valid JSON

JSON even has its own mime type. The idea of JSON as a first-class citizen
is a fallacy IMHO. The concept itsel is not ugly, but for god's sake, lets
put it in a separate RFC and lets decide con the actual RFC. Perhaps the
JSON idea could benefit from autoboxing and a native class?:
https://wiki.php.net/rfc/autoboxing

JSON is a serializarion format, not a data structure, you coud write an
associative array and if PHP knew the way, it could be autointerpreted as
JSON, no need to make PHP code look like JSON. I think that the *BEHAVIOR*
 of arrays/objects as JSON and without the intervention of serialization
functions should be in a separate RFC. There is really no point to make PHP
*look* like JSON to handle JSON natively .

This JSON matter and short array/object syntax are different issues just the
way "

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[David Zülke]

Just because the MongoDB developers were stupid enough to build a query 
language on top of JSON does not mean that JSON or JavaScript object literals 
need to be supported in PHP. And it wouldn't be possible anyway since JSON 
allows Unicode escape sequences, and PHP cannot even represent those as it is 
not aware of runtime encodings.

Besides, outside the use case of json_decode(), stdClass is rarely ever useful, 
so I don't understand why we're even discussing {} shorthands here. It's not in 
the RFC either, so good job on focusing on the issue and not diluting the 
discussion.

Getting back to the RFC: I think it's problematic to have two separate syntaxes 
for the key/value separator. For consistency's sake, I'd rather just have "=>" 
but not ":". Just my $0.02.

David


On 02.06.2011, at 00:09, John Crenshaw wrote:

> For small linear arrays, neither format is "more readable" but for even 
> mildly complex structures, there is a clear difference. Consider the 
> following Mongo query:
> 
> $query = array(
>'time'=>array('$and'=>array(
>array('$gt'=>strtotime('-1 day')),
>array('$lt'=>time()),
>)),
>'$or'=>array(
>array('foo'=>'bar'),
>array('hello'=>'world')
>)
> );
> 
> Vs. the JSON form:
> $query = {
>time: {'$and': [
>{'$gt': strtotime('-1 day')},
>{'$lt': time()},
>]},
>'$or': [
>{foo: 'bar'},
>{hello: 'world'}
>]
> };
> 
> Because of the clear readability difference I'll take anything, but JSON 
> would be much better than just an "array shorthand".
> 
> John Crenshaw
> Priacta, Inc.
> 
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com] 
> Sent: Wednesday, June 01, 2011 5:18 PM
> To: PHP internals
> Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
> 
> Personally, I think focusing on a character savings is the wrong
> reason to take on any problem.  I don't care how long it takes for me
> to type code.  I don't care how much extra hdd space it takes.  But
> what I do care about is how readable it is.
> 
> To me, the array shortcut syntax is pointless.  Do you really mean to
> tell me that `[1, 2]` is more readable/easier to understand than
> `array(1,2)`?  To me, it's about a wash.
> 
> However, the object shortcut syntax is a major win.  For example:
> 
> $person = new stdClass();
> $person->city = 'ogden';
> $person->state = 'ut';
> $perspn->country = 'usa';
> $person->favoriteNumbers = array(4, 12, 37, 42);
> $person->somethingWithNumbers();
> $person->unluckyNumbers = array(6, 13, 21);
> $person->likesPhp = 'very much so';
> 
> vs
> 
> $person =  { 'name' => 'Justin',
>   'city' => 'ogden',
>   'state' => 'ut',
>   'country' => 'usa',
>   'favoriteNumbers' => [ 4, 12, 37, 42],
>   'unluckyNumbers' => [ 6, 13, 21],
>   'likesPhp' => 'very much so'
> }
> 
> Did you notice what happened there?  There's two differences.  Try to
> find them.  Neither would be possible with the shortcut syntax.
> 
> Now, the only reason I would personally support the array shortcut is
> if it was an implementation of JSON.  I know that's not on the table
> here, but that's the only benefit I can see to implementing a shortcut
> for arrays (that would save 5 characters per instance).
> 
> Just my $0.02...
> 
> Anthony
> 
> On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony  
> wrote:
>> To address the soapbox:
>> 
>> Its not just to reduce the five characters at the beginning, but when you 
>> have more complex structures as well. There was already a great example 
>> shown (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) 
>> of that. Also, if object support is added (which we need to add to the RFC), 
>> you can cut down on a lot more verbose code, especially with objects.
>> 
>> $person = { 'name' => 'Justin',
>>'city' => 'ogden',
>>'state' => 'ut',
>>'country' => 'usa',
>>'favoriteNumbers' => [ 4, 12, 37, 42],
>>'unluckyNumbers' => [ 6, 13, 21],
>>'likesPhp' => 'very much so'
>> };
>> 
>> Characters: 192
>> 
>> Current way:
>> 
>> $person = new stdClass();
>> $person->city = 'ogden';
>> $person->state = 'ut';
>> $person->country = 'usa';
>> $person->favoriteNumbers = array(4, 12, 37, 42);
>> $person->unluckyNumbers = array(6, 13, 21);
>> $person->likesPhp = 'very much so';
>> 
>> Characters: 229
>> 
>> That is a 37 character difference. But the real driving factor is given 
>> PHP's lack of named parameter syntax, passing objects and arrays (or 
>> sometimes a mix, depending on the framework) is becoming very popular. So 
>> not only do you save some typing just once, but if you use this pattern a 
>> lot, you save a lot of typing over your entire project. Also, when dealing 
>> with objects, I have to make sure I retype "person" correctly each time. If 
>> I don't, I'll get a notice error. But with the new syntax, it'll throw a 
>> parsing error so I can know a lot quicker what my issue is.
>> 
>> As for syntax highlighters, IDEs, bo

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

hi Chris

On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
 wrote:
>
>
> On 06/01/2011 03:09 AM, Pierre Joye wrote:
>
>> URL: https://wiki.php.net/rfc/releaseprocess
>
> Pierre,
>
> There are some immediately practical things here.  Some things will
> be a large jolt for the community and might be better introduced in
> future releases.
>
> Chris
>
> Good:
>  - Scheduled releases
>  - Use of RFCs
>  - No PHP script breakages in x.y.z+1 releases
>
> Too complex or not good:
>  - Number of concurrent branches: Johannes's suggestion was good

This proposal for distros not for programming languages or similar
tools. All users I talk to need fixed timeline, life cycle, etc. to
have a clear and plan-able way to deal with php versions.

>  - Secret voting & automated polls: many things are not binary
>    decisions and need discussion

There is no secret voting.

>  - Feature preview release: good in theory.  Is there any need to
>    formalize this since anyone can create a patch (or fork etc)?

Yes, just to explain what it is and tell devs they can do it and (<
that's important) publish it.

> Define & clarify for the lay reader:
>  - "External API", "Internal API", ABI, "internals", "userland"

On it :)

-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Benjamin Eberlei]

On Wed, 1 Jun 2011 10:27:36 -0400, Sean Coates wrote:

This discussion seems to lack real-world examples…

Derick wrote:
I'm still -1 on it. It makes absolutely unreadable code (yes, also 
in

JavaScript with f.e. MongoDB).



Here's an actual snippet from my production code (which interfaces
with ElasticSearch):
http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html

If you consider this readable, you're fare more literate than I will
ever be (-:



Imho, this example just lacks a good OO abstraction (Query Builder) 
that has a toMongoQueryArray() method.



…

Gustavo wrote:


$a[array()];

is much more clear than

$a[[]]


Anyone who considers themselves skilled enough to participate in a
language-forming discussion like this one should also have the
prerequisite ability to determine that using an [empty] array as an
array key is a horrible idea, and they deserve whatever weirdness
ensues. IMO.

S



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Christopher Jones]

On 06/01/2011 03:09 AM, Pierre Joye wrote:


URL: https://wiki.php.net/rfc/releaseprocess


Pierre,

There are some immediately practical things here.  Some things will
be a large jolt for the community and might be better introduced in
future releases.

Chris

Good:
  - Scheduled releases
  - Use of RFCs
  - No PHP script breakages in x.y.z+1 releases

Too complex or not good:
  - Number of concurrent branches: Johannes's suggestion was good
  - Secret voting & automated polls: many things are not binary
decisions and need discussion
  - Feature preview release: good in theory.  Is there any need to
formalize this since anyone can create a patch (or fork etc)?

Define & clarify for the lay reader:
  - "External API", "Internal API", ABI, "internals", "userland"


--
Email: christopher.jo...@oracle.com
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

On Thu, Jun 2, 2011 at 12:22 AM, Marcel Esser  wrote:

> It's also not about PHP vs Node in any way; it's about interacting with
> APIs that make heavy use of JSON or JSON-superset notations.

PHP supports json since years, http://www.php.net/json_decode /
encode, as well as many other serialization formats that almost no
human being can read. That does make it a better candidate for the PHP
source code.

-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[John Crenshaw]

I'm suddenly realizing that the actual need is, in many cases, specific to the 
development circumstances. When developing heavily against/with other systems 
that use JSON (like MongoDB, jQuery, various APIs, etc.) the value of true JSON 
is immeasurable, and anything that isn't JSON would look wrong in that code. On 
the other hand, something like ZendFramework may likely look better with 
something that is more internally consistent, (if it even uses the shorter 
syntax at all) since the primary emphasis of the code is PHP.

What if both syntaxes are allowed (both pure JSON, and the PHP-like => syntax)? 
Individual projects could gravitate to the format that makes the most sense on 
a case by case basis.

John Crenshaw
Priacta, Inc.

-Original Message-
From: Sean Coates [mailto:s...@seancoates.com] 
Sent: Wednesday, June 01, 2011 6:09 PM
To: Anthony Ferrara
Cc: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

> Now, the only reason I would personally support the array shortcut is
> if it was an implementation of JSON.  I know that's not on the table
> here

I don't think anything is officially off the table, unless we forego discussion.

My application is largely JSON-powered. We pass data from back- to front-end 
via JSON, we interact with MongoDB via the extension (which is an altered 
JSON-like protocol (arrays instead of objects), but would be a lot more fluent 
with actual objects-they're just too hard to make in current PHP), and we 
interface with ElasticSearch. The paste I linked earlier is our primary 
ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching; especially 
when interacting with systems like the ones I've mentioned. There's a huge 
amount of value in being able to copy JSON out of PHP and into e.g. CURL to 
make a query to ElasticSearch without worrying that I've accidentally nested 
one level too deep or shallow, or accidentally mistranslating my arrays into 
JSON.

This is not about saving five characters every time I type array(), it's about 
making my systems all work together in a way that's a little less abstracted, 
and a lot less prone to error.

S
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Sanford Whiteman]

> Vs. the JSON form:
> {
> time: {'$and': [
> {'$gt': strtotime('-1 day')},
> {'$lt': time()},
> ]},
> '$or': [
> {foo: 'bar'},
> {hello: 'world'}
> ]
> }

That  isn't  valid  JSON  for  many  different reasons... if you think
that's "pure JSON," you need to spend some time with JSONLint.

If  you  (and  others)  mean  "Javascript  object  literal,"  say  it.
(Similarly, if you mean "Javascript," don't say "jQuery" .)

-- S.





-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

On Thu, Jun 2, 2011 at 12:10 AM, Zeev Suraski  wrote:
>> However, what you refer to is about internals API. We can (and did a
>> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
>> (read: signatures, source compatibility) if possible.
>
> I think we need to clear it up in the RFC.  My take:
>
> - Switch from talking about 'ABI' to 'extension API'
> - Divide the extension API into source-level and binary-level
> - For x.y+1, make it clear that there's no need to retain binary-level 
> extension API, and that source-level extension API is a 'should' and not a 
> 'must'.

On it, adding the reference to ABI/API definition as well.

-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Sean Coates]

> Why not make your data in JSON and then $foo = json_encode($data) ?

For exactly the same reason people actually use callbacks efficiently, now that 
they don't have to create_function() them.

S


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Marcel Esser]

Parsing together strings that mix single and double quotes, variables,
defined constants and etc, makes the problem significantly worse, not
better. So, json_encode is not a solution at all.

It's also not about PHP vs Node in any way; it's about interacting with
APIs that make heavy use of JSON or JSON-superset notations.

- M.

-- 
Marcel Esser

Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com

Before printing this e-mail, please consider the rainforest.




On 6/1/11 6:17 PM, "Michael Shadle"  wrote:

>On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates  wrote:
>
>> This is not about saving five characters every time I type array(),
>>it's about making my systems all work together in a way that's a little
>>less abstracted, and a lot less prone to error.
>
>Why not make your data in JSON and then $foo = json_encode($data) ?
>
>Why try to adopt JSON to PHP, just so it matches another language's
>format?
>
>You do realize adding JavaScript syntax for arrays will only make that
>consistent with JavaScript, otherwise you're still coding PHP with PHP
>syntax, functions, etc. for everything else. That argument seems moot.
>If you're more comfortable with JavaScript, start developing in node
>if that is your cup of tea.
>
>-- 
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Michael Shadle]

On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates  wrote:

> This is not about saving five characters every time I type array(), it's 
> about making my systems all work together in a way that's a little less 
> abstracted, and a lot less prone to error.

Why not make your data in JSON and then $foo = json_encode($data) ?

Why try to adopt JSON to PHP, just so it matches another language's format?

You do realize adding JavaScript syntax for arrays will only make that
consistent with JavaScript, otherwise you're still coding PHP with PHP
syntax, functions, etc. for everything else. That argument seems moot.
If you're more comfortable with JavaScript, start developing in node
if that is your cup of tea.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Marcel Esser]

I've been giving it some more thought, and really, the more I think about
it, the more I am with Sean on the idea of having first-class JSON
support. It really just makes sense. PHP is a web-oriented language, and
we will all use it at some point. It's also very concise, and it's really
easy to learn.

It really just makes things easier in the long run. X APIs are adopting
JSON as a query format, hence, if we can support JSON fully, the learning
curve for expressing these queries gets sliced and diced. And as Sean
said, a lot less error prone.

Cheers,
M.

-- 
Marcel Esser

Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com

Before printing this e-mail, please consider the rainforest.




On 6/1/11 6:09 PM, "Sean Coates"  wrote:

>> Now, the only reason I would personally support the array shortcut is
>> if it was an implementation of JSON.  I know that's not on the table
>> here
>
>I don't think anything is officially off the table, unless we forego
>discussion.
>
>My application is largely JSON-powered. We pass data from back- to
>front-end via JSON, we interact with MongoDB via the extension (which is
>an altered JSON-like protocol (arrays instead of objects), but would be a
>lot more fluent with actual objects‹they're just too hard to make in
>current PHP), and we interface with ElasticSearch. The paste I linked
>earlier is our primary ElasticSearch query.
>
>The benefits of first-class JSON are important and wide-reaching;
>especially when interacting with systems like the ones I've mentioned.
>There's a huge amount of value in being able to copy JSON out of PHP and
>into e.g. CURL to make a query to ElasticSearch without worrying that
>I've accidentally nested one level too deep or shallow, or accidentally
>mistranslating my arrays into JSON.
>
>This is not about saving five characters every time I type array(), it's
>about making my systems all work together in a way that's a little less
>abstracted, and a lot less prone to error.
>
>S
>-- 
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

On Wed, Jun 1, 2011 at 11:59 PM, John Crenshaw  wrote:
> Spot on. It has nothing to do with extra typing (and that sort of design is 
> part of what ruined Ruby). My fingers move plenty fast and if extra 
> characters make things more safe or more readable, I'll be the first to sign 
> up. In this case, however, the extra characters just make things messy.
> 1. The most readable format is pure JSON
> 2. The most familiar format is pure JSON (because these same developers are 
> almost certainly already using it in their jQuery code)
> 3. The most compact format is pure JSON
> 4. The format most consistent with other languages is JSON

Not sure which other language you refer to but python, C, perl (using
() instead) uses a very similar format.

To me using json (a serializer format) in code sounds wrong, very
wrong, in the 1st place. What's the next step? Bson? Using JSON in the
code also won't save anyone from any kind of conversions errors from
or to JSON.

This RFC proposed two syntaxes, which can be later extended to object
as well if desired. I would stronlgy suggest to focus on this RFC and
get it sort out (accepted or rejected). If it requires to clarify the
RFC to make the voting easier, then let do it.

Cheers,
-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Final version, RFC release process

[Zeev Suraski]

> However, what you refer to is about internals API. We can (and did a
> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
> (read: signatures, source compatibility) if possible.

I think we need to clear it up in the RFC.  My take:

- Switch from talking about 'ABI' to 'extension API' 
- Divide the extension API into source-level and binary-level
- For x.y+1, make it clear that there's no need to retain binary-level 
extension API, and that source-level extension API is a 'should' and not a 
'must'.

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[John Crenshaw]

For small linear arrays, neither format is "more readable" but for even mildly 
complex structures, there is a clear difference. Consider the following Mongo 
query:

$query = array(
'time'=>array('$and'=>array(
array('$gt'=>strtotime('-1 day')),
array('$lt'=>time()),
)),
'$or'=>array(
array('foo'=>'bar'),
array('hello'=>'world')
)
);

Vs. the JSON form:
$query = {
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
};

Because of the clear readability difference I'll take anything, but JSON would 
be much better than just an "array shorthand".

John Crenshaw
Priacta, Inc.

-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com] 
Sent: Wednesday, June 01, 2011 5:18 PM
To: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Personally, I think focusing on a character savings is the wrong
reason to take on any problem.  I don't care how long it takes for me
to type code.  I don't care how much extra hdd space it takes.  But
what I do care about is how readable it is.

To me, the array shortcut syntax is pointless.  Do you really mean to
tell me that `[1, 2]` is more readable/easier to understand than
`array(1,2)`?  To me, it's about a wash.

However, the object shortcut syntax is a major win.  For example:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$perspn->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->somethingWithNumbers();
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

vs

$person =  { 'name' => 'Justin',
   'city' => 'ogden',
   'state' => 'ut',
   'country' => 'usa',
   'favoriteNumbers' => [ 4, 12, 37, 42],
   'unluckyNumbers' => [ 6, 13, 21],
   'likesPhp' => 'very much so'
}

Did you notice what happened there?  There's two differences.  Try to
find them.  Neither would be possible with the shortcut syntax.

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON.  I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).

Just my $0.02...

Anthony

On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony  wrote:
> To address the soapbox:
>
> Its not just to reduce the five characters at the beginning, but when you 
> have more complex structures as well. There was already a great example shown 
> (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of 
> that. Also, if object support is added (which we need to add to the RFC), you 
> can cut down on a lot more verbose code, especially with objects.
>
> $person = { 'name' => 'Justin',
>    'city' => 'ogden',
>    'state' => 'ut',
>    'country' => 'usa',
>    'favoriteNumbers' => [ 4, 12, 37, 42],
>    'unluckyNumbers' => [ 6, 13, 21],
>    'likesPhp' => 'very much so'
> };
>
> Characters: 192
>
> Current way:
>
> $person = new stdClass();
> $person->city = 'ogden';
> $person->state = 'ut';
> $person->country = 'usa';
> $person->favoriteNumbers = array(4, 12, 37, 42);
> $person->unluckyNumbers = array(6, 13, 21);
> $person->likesPhp = 'very much so';
>
> Characters: 229
>
> That is a 37 character difference. But the real driving factor is given PHP's 
> lack of named parameter syntax, passing objects and arrays (or sometimes a 
> mix, depending on the framework) is becoming very popular. So not only do you 
> save some typing just once, but if you use this pattern a lot, you save a lot 
> of typing over your entire project. Also, when dealing with objects, I have 
> to make sure I retype "person" correctly each time. If I don't, I'll get a 
> notice error. But with the new syntax, it'll throw a parsing error so I can 
> know a lot quicker what my issue is.
>
> As for syntax highlighters, IDEs, books, etc all being outdated, first off no 
> one is suggesting to deprecate the array() function. So you will only use 
> this new syntax if you choose to do so. Second, we broke syntax highlighters, 
> IDEs, and so forth when we introduced namespaces, and every IDE and syntax 
> highlighter I used updated very quickly to support them. I'm assuming the 
> IDEs spent a great deal more time adding Namespacing support than it will to 
> support a short syntax for arrays and objects.
>
> PHP has made short syntax for other things, such a if statement short codes. 
> Yet many books don't cover it, since it is one of those things you read in 
> the documentation later and decide "Do I want to use this?" No one is forcing 
> anyone to use (1 == 1 ? true : false) type of if/then logic. The same will 
> work with the new syntax.
>
> My two cents.
>
> Justin
>
> On Jun 1, 2011, at 2:37 PM, Michael Shadle wrote:
>
>> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye  wrote:
>>
>>> I modified the vote page, pls move your votes to the

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Sean Coates]

> Now, the only reason I would personally support the array shortcut is
> if it was an implementation of JSON.  I know that's not on the table
> here

I don't think anything is officially off the table, unless we forego discussion.

My application is largely JSON-powered. We pass data from back- to front-end 
via JSON, we interact with MongoDB via the extension (which is an altered 
JSON-like protocol (arrays instead of objects), but would be a lot more fluent 
with actual objects—they're just too hard to make in current PHP), and we 
interface with ElasticSearch. The paste I linked earlier is our primary 
ElasticSearch query.

The benefits of first-class JSON are important and wide-reaching; especially 
when interacting with systems like the ones I've mentioned. There's a huge 
amount of value in being able to copy JSON out of PHP and into e.g. CURL to 
make a query to ElasticSearch without worrying that I've accidentally nested 
one level too deep or shallow, or accidentally mistranslating my arrays into 
JSON.

This is not about saving five characters every time I type array(), it's about 
making my systems all work together in a way that's a little less abstracted, 
and a lot less prone to error.

S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[John Crenshaw]

Spot on. It has nothing to do with extra typing (and that sort of design is 
part of what ruined Ruby). My fingers move plenty fast and if extra characters 
make things more safe or more readable, I'll be the first to sign up. In this 
case, however, the extra characters just make things messy.
1. The most readable format is pure JSON
2. The most familiar format is pure JSON (because these same developers are 
almost certainly already using it in their jQuery code)
3. The most compact format is pure JSON
4. The format most consistent with other languages is JSON

John Crenshaw
Priacta, Inc.

-Original Message-
From: Chris Stockton [mailto:chrisstockto...@gmail.com] 
Sent: Wednesday, June 01, 2011 5:23 PM
To: Michael Shadle
Cc: Pierre Joye; PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

Hello,

On Wed, Jun 1, 2011 at 1:37 PM, Michael Shadle  wrote:
> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye  wrote:
>
> 5 character difference for each array being saved. That's it. At the
> expense of syntax highlighters, IDEs, books, all becoming outdated and
> need to be updated. For a language construct that has been around for
> what, 10 years?
>

My desire and perhaps the viewpoint of many others to use ":" over
"=>" has very little to do with typing a extra character. This feature
I have seen brought up on the list time and time again, some 8 years
ago being the first. Just recently more people are in favor of it I'm
sure largely due to the common use and readability of JSON. I
understand this discussion is for "array shorthand syntax.." but I
think really people just want to define their data structures like
they do in JSON, I would hate to see such a common and familiar syntax
be changed just for the sake of principal/familiarity.

The take away from this is simply: I think we would be butchering a
very clean, precise and extremely familiar syntax if we use => just to
be "PHP".

-Chris

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Michael Shadle]

First, why not go the opposite way and standardize the syntax - why
not make object() or Object() work like array() or Array()?

$person = object('name' => 'Justin',
    'city' => 'ogden',
    'state' => 'ut',
    'country' => 'usa',
    'favoriteNumbers' => array(4, 12, 37, 42),
    'unluckyNumbers' => array(6, 13, 21),
    'likesPhp' => 'very much so'
);

Then you maintain consistency instead of relying on specific
characters. That makes more sense than trying to make shorthand for
something so basic to the language. I remember moving from Perl to PHP
I remember thinking "what the hell? Everything is a $, how do you make
hashes?"

Secondly,

"Second, we broke syntax highlighters, IDEs, and so forth when we
introduced namespaces"

Don't get me started on namespaces. :)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Chris Stockton]

Hello,

On Wed, Jun 1, 2011 at 2:17 PM, Anthony Ferrara  wrote:
> Personally, I think focusing on a character savings is the wrong
> reason to take on any problem.  I don't care how long it takes for me
> to type code.  I don't care how much extra hdd space it takes.  But
> what I do care about is how readable it is.
>
> To me, the array shortcut syntax is pointless.  Do you really mean to
> tell me that `[1, 2]` is more readable/easier to understand than
> `array(1,2)`?  To me, it's about a wash.
>
> However, the object shortcut syntax is a major win.  For example:
>
> $person = new stdClass();
> $person->city = 'ogden';
> $person->state = 'ut';
> $perspn->country = 'usa';
> $person->favoriteNumbers = array(4, 12, 37, 42);
> $person->somethingWithNumbers();
> $person->unluckyNumbers = array(6, 13, 21);
> $person->likesPhp = 'very much so';
>
> vs
>
> $person =  { 'name' => 'Justin',
>   'city' => 'ogden',
>   'state' => 'ut',
>   'country' => 'usa',
>   'favoriteNumbers' => [ 4, 12, 37, 42],
>   'unluckyNumbers' => [ 6, 13, 21],
>   'likesPhp' => 'very much so'
> }
>
> Did you notice what happened there?  There's two differences.  Try to
> find them.  Neither would be possible with the shortcut syntax.
>

I don't think doing this is a very big deal, even in the case of Array().
 $person = (object) [ 'name' => 'Justin',
   'city' => 'ogden',
   'state' => 'ut',
   'country' => 'usa',
   'favoriteNumbers' => [ 4, 12, 37, 42],
   'unluckyNumbers' => [ 6, 13, 21],
   'likesPhp' => 'very much so'
 ]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Chris Stockton]

Hello,

On Wed, Jun 1, 2011 at 1:37 PM, Michael Shadle  wrote:
> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye  wrote:
>
> 5 character difference for each array being saved. That's it. At the
> expense of syntax highlighters, IDEs, books, all becoming outdated and
> need to be updated. For a language construct that has been around for
> what, 10 years?
>

My desire and perhaps the viewpoint of many others to use ":" over
"=>" has very little to do with typing a extra character. This feature
I have seen brought up on the list time and time again, some 8 years
ago being the first. Just recently more people are in favor of it I'm
sure largely due to the common use and readability of JSON. I
understand this discussion is for "array shorthand syntax.." but I
think really people just want to define their data structures like
they do in JSON, I would hate to see such a common and familiar syntax
be changed just for the sake of principal/familiarity.

The take away from this is simply: I think we would be butchering a
very clean, precise and extremely familiar syntax if we use => just to
be "PHP".

-Chris

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Anthony Ferrara]

Personally, I think focusing on a character savings is the wrong
reason to take on any problem.  I don't care how long it takes for me
to type code.  I don't care how much extra hdd space it takes.  But
what I do care about is how readable it is.

To me, the array shortcut syntax is pointless.  Do you really mean to
tell me that `[1, 2]` is more readable/easier to understand than
`array(1,2)`?  To me, it's about a wash.

However, the object shortcut syntax is a major win.  For example:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$perspn->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->somethingWithNumbers();
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

vs

$person =  { 'name' => 'Justin',
   'city' => 'ogden',
   'state' => 'ut',
   'country' => 'usa',
   'favoriteNumbers' => [ 4, 12, 37, 42],
   'unluckyNumbers' => [ 6, 13, 21],
   'likesPhp' => 'very much so'
}

Did you notice what happened there?  There's two differences.  Try to
find them.  Neither would be possible with the shortcut syntax.

Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON.  I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).

Just my $0.02...

Anthony

On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony  wrote:
> To address the soapbox:
>
> Its not just to reduce the five characters at the beginning, but when you 
> have more complex structures as well. There was already a great example shown 
> (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of 
> that. Also, if object support is added (which we need to add to the RFC), you 
> can cut down on a lot more verbose code, especially with objects.
>
> $person = { 'name' => 'Justin',
>    'city' => 'ogden',
>    'state' => 'ut',
>    'country' => 'usa',
>    'favoriteNumbers' => [ 4, 12, 37, 42],
>    'unluckyNumbers' => [ 6, 13, 21],
>    'likesPhp' => 'very much so'
> };
>
> Characters: 192
>
> Current way:
>
> $person = new stdClass();
> $person->city = 'ogden';
> $person->state = 'ut';
> $person->country = 'usa';
> $person->favoriteNumbers = array(4, 12, 37, 42);
> $person->unluckyNumbers = array(6, 13, 21);
> $person->likesPhp = 'very much so';
>
> Characters: 229
>
> That is a 37 character difference. But the real driving factor is given PHP's 
> lack of named parameter syntax, passing objects and arrays (or sometimes a 
> mix, depending on the framework) is becoming very popular. So not only do you 
> save some typing just once, but if you use this pattern a lot, you save a lot 
> of typing over your entire project. Also, when dealing with objects, I have 
> to make sure I retype "person" correctly each time. If I don't, I'll get a 
> notice error. But with the new syntax, it'll throw a parsing error so I can 
> know a lot quicker what my issue is.
>
> As for syntax highlighters, IDEs, books, etc all being outdated, first off no 
> one is suggesting to deprecate the array() function. So you will only use 
> this new syntax if you choose to do so. Second, we broke syntax highlighters, 
> IDEs, and so forth when we introduced namespaces, and every IDE and syntax 
> highlighter I used updated very quickly to support them. I'm assuming the 
> IDEs spent a great deal more time adding Namespacing support than it will to 
> support a short syntax for arrays and objects.
>
> PHP has made short syntax for other things, such a if statement short codes. 
> Yet many books don't cover it, since it is one of those things you read in 
> the documentation later and decide "Do I want to use this?" No one is forcing 
> anyone to use (1 == 1 ? true : false) type of if/then logic. The same will 
> work with the new syntax.
>
> My two cents.
>
> Justin
>
> On Jun 1, 2011, at 2:37 PM, Michael Shadle wrote:
>
>> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye  wrote:
>>
>>> I modified the vote page, pls move your votes to the desired syntax
>>> (or global -1)
>>
>> This is a good idea to group things like this.
>>
>> Back on the soapbox. All of this is just to reduce typing "array" (5
>> characters) before things?
>>
>> Old:
>> $foo = array('a' => 'b', 'c' => 'd');
>>
>> More than likely new:
>> $foo = ['a' => 'b', 'c' => 'd'];
>>
>> 5 character difference for each array being saved. That's it. At the
>> expense of syntax highlighters, IDEs, books, all becoming outdated and
>> need to be updated. For a language construct that has been around for
>> what, 10 years?
>>
>> Oh, and for anyone desiring a ":" for this new shorthand, why stop at
>> array shorthand. Why not change this from:
>> foreach($foo as $key => $val)
>>
>> To:
>> foreach($foo as $key: $val)
>>
>> That would save one character for each array iteration like that.
>>
>> Also - if we're worried about saving characters and shorthand why not
>> just remove the "$" language constr

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Justin Carmony]

To address the soapbox:

Its not just to reduce the five characters at the beginning, but when you have 
more complex structures as well. There was already a great example shown 
(http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of that. 
Also, if object support is added (which we need to add to the RFC), you can cut 
down on a lot more verbose code, especially with objects.

$person = { 'name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => [ 4, 12, 37, 42],
'unluckyNumbers' => [ 6, 13, 21],
'likesPhp' => 'very much so'
};

Characters: 192

Current way:

$person = new stdClass();
$person->city = 'ogden';
$person->state = 'ut';
$person->country = 'usa';
$person->favoriteNumbers = array(4, 12, 37, 42);
$person->unluckyNumbers = array(6, 13, 21);
$person->likesPhp = 'very much so';

Characters: 229

That is a 37 character difference. But the real driving factor is given PHP's 
lack of named parameter syntax, passing objects and arrays (or sometimes a mix, 
depending on the framework) is becoming very popular. So not only do you save 
some typing just once, but if you use this pattern a lot, you save a lot of 
typing over your entire project. Also, when dealing with objects, I have to 
make sure I retype "person" correctly each time. If I don't, I'll get a notice 
error. But with the new syntax, it'll throw a parsing error so I can know a lot 
quicker what my issue is.

As for syntax highlighters, IDEs, books, etc all being outdated, first off no 
one is suggesting to deprecate the array() function. So you will only use this 
new syntax if you choose to do so. Second, we broke syntax highlighters, IDEs, 
and so forth when we introduced namespaces, and every IDE and syntax 
highlighter I used updated very quickly to support them. I'm assuming the IDEs 
spent a great deal more time adding Namespacing support than it will to support 
a short syntax for arrays and objects.

PHP has made short syntax for other things, such a if statement short codes. 
Yet many books don't cover it, since it is one of those things you read in the 
documentation later and decide "Do I want to use this?" No one is forcing 
anyone to use (1 == 1 ? true : false) type of if/then logic. The same will work 
with the new syntax.

My two cents.

Justin

On Jun 1, 2011, at 2:37 PM, Michael Shadle wrote:

> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye  wrote:
> 
>> I modified the vote page, pls move your votes to the desired syntax
>> (or global -1)
> 
> This is a good idea to group things like this.
> 
> Back on the soapbox. All of this is just to reduce typing "array" (5
> characters) before things?
> 
> Old:
> $foo = array('a' => 'b', 'c' => 'd');
> 
> More than likely new:
> $foo = ['a' => 'b', 'c' => 'd'];
> 
> 5 character difference for each array being saved. That's it. At the
> expense of syntax highlighters, IDEs, books, all becoming outdated and
> need to be updated. For a language construct that has been around for
> what, 10 years?
> 
> Oh, and for anyone desiring a ":" for this new shorthand, why stop at
> array shorthand. Why not change this from:
> foreach($foo as $key => $val)
> 
> To:
> foreach($foo as $key: $val)
> 
> That would save one character for each array iteration like that.
> 
> Also - if we're worried about saving characters and shorthand why not
> just remove the "$" language construct? That's a LOT of keystrokes. In
> my WordPress install, that's 75,412 characters saved. Versus 6,960
> "array(" matches, which would save 34,800 characters.
> 
> These were quick examples from a coworker. Just another PHP user who
> said "wait why would they make another way to express an array?"
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Michael Shadle]

On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye  wrote:

> I modified the vote page, pls move your votes to the desired syntax
> (or global -1)

This is a good idea to group things like this.

Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?

Old:
$foo = array('a' => 'b', 'c' => 'd');

More than likely new:
$foo = ['a' => 'b', 'c' => 'd'];

5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
need to be updated. For a language construct that has been around for
what, 10 years?

Oh, and for anyone desiring a ":" for this new shorthand, why stop at
array shorthand. Why not change this from:
foreach($foo as $key => $val)

To:
foreach($foo as $key: $val)

That would save one character for each array iteration like that.

Also - if we're worried about saving characters and shorthand why not
just remove the "$" language construct? That's a LOT of keystrokes. In
my WordPress install, that's 75,412 characters saved. Versus 6,960
"array(" matches, which would save 34,800 characters.

These were quick examples from a coworker. Just another PHP user who
said "wait why would they make another way to express an array?"

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Philip Olson]

On Jun 1, 2011, at 12:43 PM, Pierre Joye wrote:

> On Wed, Jun 1, 2011 at 9:38 PM, Philip Olson  wrote:
> 
>> I'm choosing to ignore this voting mechanism because it feels wrong.
> 
> 
> We always voted based on php.net accounts (@php.net that is), whether
> it is a good thing or not is another question and unrelated to this
> RFC (for one, I consider that non php.net people should have a voice,
> iirc).

But this discussion started off so well with true brain storming and ideas 
coming to light. People started discussing the pros and cons, people saw and 
began understanding the different angles, and then some people grew tired and 
forced a premature vote. Yes it got a little messy, but such is life. --voting.

And besides, it's rare that a tallied vote is required because typically a real 
consensus can be reached.

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Ferenc Kovacs]

>
>
> > David
>
> David who? :)
>
>
David Vega

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

On Wed, Jun 1, 2011 at 9:43 PM, dukeofgaming  wrote:

> Yup, it feels rushed. The RFC should be cleaned up and I think this are the
> main items:
> - Ditch ":"
> - Ditch the JSON topic or open a separate RFC with it
> - Introduce the "{ }" syntax for objects and change the title

Both json and objects are not part of the RFC. It could be added later
or in a new one.

I modified the vote page, pls move your votes to the desired syntax
(or global -1)

> David

David who? :)

-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[dukeofgaming]

On Wed, Jun 1, 2011 at 2:38 PM, Philip Olson  wrote:

> >>> Reminder: Pls add your votes here:
> >>> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
> >>
> >>
> >> Who is allowed to vote?, are userland votes still going to count?, if
> so,
> >> how does one qualify as userland voter?.
>
> >
> > I think the one that is active can be a voter.
> > Or maybe the ones that have any karma on php environment is considered a
> voter.
>
> I'm choosing to ignore this voting mechanism because it feels wrong. And
> besides, this RFC is outdated and still being reviewed for comments. In
> other words, nobody knows what they are voting on.
>
> Regards,
> Philip
>
>
Yup, it feels rushed. The RFC should be cleaned up and I think this are the
main items:

- Ditch ":"
- Ditch the JSON topic or open a separate RFC with it
- Introduce the "{ }" syntax for objects and change the title

Regards,

David

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

On Wed, Jun 1, 2011 at 9:38 PM, Philip Olson  wrote:

> I'm choosing to ignore this voting mechanism because it feels wrong.


We always voted based on php.net accounts (@php.net that is), whether
it is a good thing or not is another question and unrelated to this
RFC (for one, I consider that non php.net people should have a voice,
iirc).

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Philip Olson]

>>> Reminder: Pls add your votes here:
>>> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>> 
>> 
>> Who is allowed to vote?, are userland votes still going to count?, if so,
>> how does one qualify as userland voter?.

> 
> I think the one that is active can be a voter.
> Or maybe the ones that have any karma on php environment is considered a 
> voter.

I'm choosing to ignore this voting mechanism because it feels wrong. And 
besides, this RFC is outdated and still being reviewed for comments. In other 
words, nobody knows what they are voting on.

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[guilhermebla...@gmail.com]

I think the one that is active can be a voter.
Or maybe the ones that have any karma on php environment is considered a voter.

Cheers,

On Wed, Jun 1, 2011 at 4:21 PM, dukeofgaming  wrote:
> On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye  wrote:
>
>> Reminder: Pls add your votes here:
>> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>
>
> Who is allowed to vote?, are userland votes still going to count?, if so,
> how does one qualify as userland voter?.
>
> Best regards,
>
> David Vega
>



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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[dukeofgaming]

On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye  wrote:

> Reminder: Pls add your votes here:
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote


Who is allowed to vote?, are userland votes still going to count?, if so,
how does one qualify as userland voter?.

Best regards,

David Vega

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Chris Stockton]

Hi Lester,

On Wed, Jun 1, 2011 at 11:19 AM, Lester Caine  wrote:
> Chris Stockton wrote:
>>>
>>> Reminder: Pls add your votes here:
>>> >  https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>>> >
>>
>> May I please have wiki rights restored to my user "cstockton" if
>> possible, I would like to vote.
>
> It would seem some people have not been watching the news?
> http://www.php.net/ top news item ...
> But it would seem that the 'change password' processes is not being flagged
> properly?
>

I did read that a couple months back, reset my password and logged in
numerous times since (I am logged in now). However I am not able to
edit articles anymore (or maybe never could?). Getting that access
would be appreciated.

Thanks,

-Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Lester Caine]

Chris Stockton wrote:

Reminder: Pls add your votes here:
>  https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>

May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.


It would seem some people have not been watching the news?
http://www.php.net/ top news item ...
But it would seem that the 'change password' processes is not being flagged 
properly?


--
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Chris Stockton]

Hello,

On Wed, Jun 1, 2011 at 10:19 AM, Pierre Joye  wrote:
> Reminder: Pls add your votes here:
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>

May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

On Tue, May 31, 2011 at 8:42 PM, Brian Moon  wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core
> developers voted against. Though if you take a accumulated mean between core
> developers and userland votes seems to show the opposite it would be
> irresponsible to submit a patch witch is not supported or maintained in the
> long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or did
> not see the use of it. From rereading the mailing list archive, most had the
> tone of "I don't see a reason for it." I was in that camp in 2003 when it
> first came up. However, with the emergence of JSON and systems that use JSON
> as an interface, this type of syntax would be most welcome in the day to day
> life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
> page) below would like to change your vote or if you are not listed below
> and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
> Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> 
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>
> --
> Brian.
> http://brian.moonspot.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

On Wed, Jun 1, 2011 at 6:47 PM, Dmitry Stogov  wrote:
> Before now each major (5.y+1) release introduced API changes.
> We just couldn't introduce literal tables, interned strings, etc without API
> changes.
>
> However such API breaks where invisible for user-land and most extensions,
> they required a lot of changes in O+, APC, xdebug, etc.
>
> But, in case we freeze the API we just won't be able to add many future
> improvements.


Userland BC must be kept between x.y and x.y+1, that's the primary
goal of this section. PHP userland is only about API compatibility and
how PHP behaves.

However, what you refer to is about internals API. We can (and did a
lot) break ABI between x.y and x.y+1 and should really avoid breaking
API (read: signatures, source compatibility) if possible.

To make it more clear, here are some good explanations about API and ABI:

http://stackoverflow.com/questions/3784389/difference-between-api-and-abi
http://en.wikipedia.org/wiki/Application_binary_interface
http://en.wikipedia.org/wiki/Application_programming_interface


-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Stas Malyshev]

Hi!


There's something between the user level API and the ABI - which is source 
level compatibility.


That's a good point. We'd like to keep source-level incompatibilities to 
a minimum - especially for simple extensions, not like APC :) - but I 
agree it may be hard to maintain at 100% if we do engine improvements. 
Maybe we should have different criteria for something like APC (which is 
very deep in the internals) and something like memcached (which needs 
much less from internals).

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Final version, RFC release process

[Zeev Suraski]

There's something between the user level API and the ABI - which is source 
level compatibility.

What Dmitry's pointing out that if we commit to source level compatibility, 
it'll be quite limiting (based on past experience).  If we don't commit to 
source-level compatibility then we're fine.  I guess we can say we'll strive 
for source level compatibility, but not have it as a 'must'.

Zeev



> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Wednesday, June 01, 2011 7:51 PM
> To: Dmitry Stogov
> Cc: John Crenshaw; PHP internals
> Subject: Re: [PHP-DEV] Final version, RFC release process
> 
> Hi!
> 
> > Before now each major (5.y+1) release introduced API changes.
> > We just couldn't introduce literal tables, interned strings, etc
> > without API changes.
> 
> I think by API there it means PHP-level API, i.e. one exposed to the user, not
> binary API exposed to the extensions, which is meant by ABI.
> So what should be preserved is PHP function signatures, classes, syntax, INI
> settings, etc. but internals can change.
> 
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Stas Malyshev]

Hi!


Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.


I think by API there it means PHP-level API, i.e. one exposed to the 
user, not binary API exposed to the extensions, which is meant by ABI. 
So what should be preserved is PHP function signatures, classes, syntax, 
INI settings, etc. but internals can change.


--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Dmitry Stogov]

Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without 
API changes.


However such API breaks where invisible for user-land and most 
extensions, they required a lot of changes in O+, APC, xdebug, etc.


But, in case we freeze the API we just won't be able to add many future 
improvements.


Thanks. Dmitry.

On 06/01/2011 03:19 PM, John Crenshaw wrote:

That isn't measurable, so it is a suggestion, not a standard. It also creates 
serious problems in userland if APIs change. API changes lead hosts to 
literally take years to update to new versions of PHP, for fear of breaking the 
sites that host with them. What about:

Userland API compatibility of documented interfaces and behaviors must be kept. 
API internals should be backwards compatible wherever possible.

This relaxes the userland restriction just slightly to allow for changes that 
break undocumented behaviors, but leaves it basically stable and measurable. 
This also leaves the door open for internal changes if they're really needed, 
but basically suggests against it.

John Crenshaw
Priacta, Inc.

-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release process

Hi,

In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.

I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possible".

Thanks. Dmitry.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Herman Radtke]

>> Here's an actual snippet from my production code (which interfaces with 
>> ElasticSearch):
>> http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html
>>
>> If you consider this readable, you're fare more literate than I will ever be 
>> (-:
>
> Using JSON syntax would only "maybe" make it more readable, and then
> only because you would probably not format it on so many lines ;-)

For gits and shiggles I converted it to short array syntax. I
structure my arrays much like Sean does and I was of the opinion that
a shorter syntax would not improve the readability much. I have to
admit I do like the way the short syntax with the : separator looks,
though the => separator is not bad on the eyes either.

Converted snippets:
Using => separator:
http://paste.roguecoders.com/p/8c653602dee96b87f566a29b78aa4daa.html
Using : (JSON) separator:
http://paste.roguecoders.com/p/b117894e85b6f980b8390bc2828ca227.html

-- 
Herman Radtke
hermanrad...@gmail.com | http://hermanradtke.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Matt Wilson]

Would it be possible to have a vote on the various options being proposed here?

I think JSON syntax is definitely more concise and easier to type, as well as 
more convenient -- but I don't think it makes sense for PHP without changing 
how arrays work (I'm all for that, but that's a different discussion)

So for me, I'm -1 on a fudged JSON syntax with key: value syntax, even though I 
prefer that syntax over =>

But I'm => on being able to simply drop 'array' from array delcarations. 

I have a third option that I'm sure no one but me would like, what if we had 
some way to designate an item as an object, instead of an associative array? 
This could be handled either with : instead of => or {} instead of (). {} 
instead of () seems to make more sense.

('arraykey' => {'property': 'value'})

Mimicking JSON just seems pointless if we can't actually provide any benefit to 
doing so, since we'd still either have to differentiate between object/array 
*and* load via eval() (-) or json_decode() (+)

This RFC just seems premature, or at least doesn't offer enough voting options.

On Jun 1, 2011, at 10:56 AM, Rasmus wrote:

> On 06/01/2011 08:00 AM, Justin Carmony wrote:
>> In all seriousness, there is a vast majority of PHP developers who are not 
>> represented on this list. I was surprised to see someone mentioning for 
>> calling for another vote so soon after this discussion came up. Perhaps 
>> instead of debating on readability and usefulness, we actually do some 
>> research with major PHP users to get their opinions? I'm not saying we 
>> should have every PHP user in the world vote, but there are talented PHP 
>> developers who are not apart of the core that have valid and insightful 
>> views and opinions.
>> 
>> So what I would first propose is we finalize the RFC because right now it is 
>> has two options, and doesn't deal with objects. I think everyone is starting 
>> to agree "=>" is much more uniform than ":", so lets drop the ":" from the 
>> RFC. 
>> 
>> Then, lets request some feedback from reputable PHP developers, like authors 
>> of popular frameworks and PHP solutions. This way we can get some real input 
>> from people who are not on the internals email list. This can help those who 
>> make the decision on whether or not to accept the RFC aware not only of 
>> their own personal opinion and preferences, but the opinions and preferences 
>> of the PHP community as a whole.
>> 
>> I know I'm newer to the list, and don't want to step on any toes, but I 
>> think the RFC process could really benefit from getting this type of 
>> feedback.
> 
> I think it is well understood that PHP internals discussion happens on
> this internals mailing list. It is not a restricted list in any way.
> Anybody is able to participate here if they want their voice heard.
> 
> -Rasmus
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Rasmus]

On 06/01/2011 08:00 AM, Justin Carmony wrote:
> In all seriousness, there is a vast majority of PHP developers who are not 
> represented on this list. I was surprised to see someone mentioning for 
> calling for another vote so soon after this discussion came up. Perhaps 
> instead of debating on readability and usefulness, we actually do some 
> research with major PHP users to get their opinions? I'm not saying we should 
> have every PHP user in the world vote, but there are talented PHP developers 
> who are not apart of the core that have valid and insightful views and 
> opinions.
> 
> So what I would first propose is we finalize the RFC because right now it is 
> has two options, and doesn't deal with objects. I think everyone is starting 
> to agree "=>" is much more uniform than ":", so lets drop the ":" from the 
> RFC. 
> 
> Then, lets request some feedback from reputable PHP developers, like authors 
> of popular frameworks and PHP solutions. This way we can get some real input 
> from people who are not on the internals email list. This can help those who 
> make the decision on whether or not to accept the RFC aware not only of their 
> own personal opinion and preferences, but the opinions and preferences of the 
> PHP community as a whole.
> 
> I know I'm newer to the list, and don't want to step on any toes, but I think 
> the RFC process could really benefit from getting this type of feedback.

I think it is well understood that PHP internals discussion happens on
this internals mailing list. It is not a restricted list in any way.
Anybody is able to participate here if they want their voice heard.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Wiki editing privileges

[guilhermebla...@gmail.com]

You probably need to reset your password.
I had the same issue previously.

On Wed, Jun 1, 2011 at 4:50 AM, dukeofgaming  wrote:
> Hmm, I can edit pages within the RFC namespace but I cannot edit
> https://wiki.php.net/rfc.
>
> Regards,
>
> David
>
> On Wed, Jun 1, 2011 at 1:38 AM, dukeofgaming  wrote:
>
>> Thanks, I also don't think that was the case.
>>
>> Regards,
>>
>> David
>>
>>
>> On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson  wrote:
>>
>>>
>>> On May 31, 2011, at 11:05 PM, dukeofgaming wrote:
>>>
>>> > Hi,
>>> >
>>> > I remember having wiki editing privileges not so long ago, I was going
>>> to
>>> > enter and add the entry for discussions at
>>> > https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit
>>> anymore.
>>> > Would it be too much to ask to have them enabled?.
>>>
>>> I don't think anyone [intentionally] took away wiki editing rights, but
>>> you now have full access to the rfc namespace.
>>>
>>> Regards,
>>> Philip
>>>
>>>
>>
>



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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Justin Carmony]

In all seriousness, there is a vast majority of PHP developers who are not 
represented on this list. I was surprised to see someone mentioning for calling 
for another vote so soon after this discussion came up. Perhaps instead of 
debating on readability and usefulness, we actually do some research with major 
PHP users to get their opinions? I'm not saying we should have every PHP user 
in the world vote, but there are talented PHP developers who are not apart of 
the core that have valid and insightful views and opinions.

So what I would first propose is we finalize the RFC because right now it is 
has two options, and doesn't deal with objects. I think everyone is starting to 
agree "=>" is much more uniform than ":", so lets drop the ":" from the RFC. 

Then, lets request some feedback from reputable PHP developers, like authors of 
popular frameworks and PHP solutions. This way we can get some real input from 
people who are not on the internals email list. This can help those who make 
the decision on whether or not to accept the RFC aware not only of their own 
personal opinion and preferences, but the opinions and preferences of the PHP 
community as a whole.

I know I'm newer to the list, and don't want to step on any toes, but I think 
the RFC process could really benefit from getting this type of feedback.

Justin Carmony


On Jun 1, 2011, at 8:37 AM, Philip Olson wrote:

> 
> On Jun 1, 2011, at 7:30 AM, Ilia Alshanetsky wrote:
> 
>> On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates  wrote:
>>> This discussion seems to lack real-world examples…
>>> 
>>> Derick wrote:
 I'm still -1 on it. It makes absolutely unreadable code (yes, also in
 JavaScript with f.e. MongoDB).
>>> 
>>> 
>>> Here's an actual snippet from my production code (which interfaces with 
>>> ElasticSearch):
>>> http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html
>>> 
>>> If you consider this readable, you're fare more literate than I will ever 
>>> be (-:
>> 
>> Using JSON syntax would only "maybe" make it more readable, and then
>> only because you would probably not format it on so many lines ;-)
> 
> Maybe that could be a contest. Who can make this the prettiest, using either 
> a proposed or current syntax. :)
> 
> Regards,
> Philip
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Philip Olson]

On Jun 1, 2011, at 7:30 AM, Ilia Alshanetsky wrote:

> On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates  wrote:
>> This discussion seems to lack real-world examples…
>> 
>> Derick wrote:
>>> I'm still -1 on it. It makes absolutely unreadable code (yes, also in
>>> JavaScript with f.e. MongoDB).
>> 
>> 
>> Here's an actual snippet from my production code (which interfaces with 
>> ElasticSearch):
>> http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html
>> 
>> If you consider this readable, you're fare more literate than I will ever be 
>> (-:
> 
> Using JSON syntax would only "maybe" make it more readable, and then
> only because you would probably not format it on so many lines ;-)

Maybe that could be a contest. Who can make this the prettiest, using either a 
proposed or current syntax. :)

Regards,
Philip
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Ilia Alshanetsky]

On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates  wrote:
> This discussion seems to lack real-world examples…
>
> Derick wrote:
>> I'm still -1 on it. It makes absolutely unreadable code (yes, also in
>> JavaScript with f.e. MongoDB).
>
>
> Here's an actual snippet from my production code (which interfaces with 
> ElasticSearch):
> http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html
>
> If you consider this readable, you're fare more literate than I will ever be 
> (-:

Using JSON syntax would only "maybe" make it more readable, and then
only because you would probably not format it on so many lines ;-)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Sean Coates]

This discussion seems to lack real-world examples…

Derick wrote:
> I'm still -1 on it. It makes absolutely unreadable code (yes, also in 
> JavaScript with f.e. MongoDB).


Here's an actual snippet from my production code (which interfaces with 
ElasticSearch):
http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html

If you consider this readable, you're fare more literate than I will ever be (-:

…

Gustavo wrote:

> $a[array()];
> 
> is much more clear than
> 
> $a[[]]

Anyone who considers themselves skilled enough to participate in a 
language-forming discussion like this one should also have the prerequisite 
ability to determine that using an [empty] array as an array key is a horrible 
idea, and they deserve whatever weirdness ensues. IMO.

S


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Benjamin Dubois]

Hi, 

From a userland perspective, there should be absolutely no feature addition in 
a "bugfix" version (x.y.Z+1) : we would see (just like what we see today) 
frameworks, apps, or libraries depending on specific bugfix releases, and this 
would not make php versioning easier to understand for anybody. 

And for you core devs, this is an open window for bypassing the standard 
versioning process, which could result in long discussions or determining if a 
feature is a self-containing one or not, and should be released in a bugfix 
version.

Allowing these exceptions would not IMO enhance the release process...

Cheers
-- 
Benjamin Dubois


Le mercredi 1 juin 2011 à 12:09, Pierre Joye a écrit :

> Hi,
> 
> Long due but finally sending the final RFC for the release process.
> 
> There a couple of changes since the last time, they are all about
> making it more transparent or catch the edge cases. We also got new
> proposers on board, we are now basically almost all active devs on
> board.
> 
> URL: https://wiki.php.net/rfc/releaseprocess
> 
> In parallel to the current discussions about 5.4's features, let get
> this RFC approved and use right away for 5.3 (to define its life time)
> and 5.4. That will spare us the issues we had in the past with 5.3,
> for example and ensure that we get 5.4 release in a reasonable
> timeframe and without endless delays, or features additions.
> 
> It is important to keep in mind that this RFC is not written in stone
> but it is a good base to begin with. We can always adapt it later, if
> necessary.
> 
> https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add
> your svn id. Proposers do not need to do it as they are indeed there
> as +1 already (I added myself as example)
> 
> Cheers,
> --
> Pierre
> 
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Jonathan Wage]

+1

On Tue, May 31, 2011 at 1:42 PM, Brian Moon  wrote:

> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus (
> http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core
> developers voted against. Though if you take a accumulated mean between core
> developers and userland votes seems to show the opposite it would be
> irresponsible to submit a patch witch is not supported or maintained in the
> long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or
> did not see the use of it. From rereading the mailing list archive, most had
> the tone of "I don't see a reason for it." I was in that camp in 2003 when
> it first came up. However, with the emergence of JSON and systems that use
> JSON as an interface, this type of syntax would be most welcome in the day
> to day life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
> page) below would like to change your vote or if you are not listed below
> and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
> Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> 
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>
> --
> Brian.
> http://brian.moonspot.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
Connect with me on *http://twitter.com/jwage* 
 and http://about.me/jwage to keep in touch.

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

2011/6/1 Ilia Alshanetsky :
> Pierre,
>
> Doing a release could be simplified through automation as you've said.
> However keeping synchronized patches across frequently incompatible
> (non-identical) code bases is much less trivial and requires quite a
> bit of work by anyone making the bug fixes. Having >3 branches for bug
> fixes makes this very non-trivial and time consuming, which is why
> Johannes' proposal is so appealing.

I don't think we will ever have >3 releases for bug fixes but maybe
3-4 max with 2-3 in security modes. In this case it is really easy to
maintain and release.

Random LTS at random point with random life time for releases is not
something I want for PHP. It is basically what we have now and PHP
users are really not happy about that (and many devs).

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Ilia Alshanetsky]

Pierre,

Doing a release could be simplified through automation as you've said.
However keeping synchronized patches across frequently incompatible
(non-identical) code bases is much less trivial and requires quite a
bit of work by anyone making the bug fixes. Having >3 branches for bug
fixes makes this very non-trivial and time consuming, which is why
Johannes' proposal is so appealing.

2011/6/1 Pierre Joye :
> hi,
>
>
> 2011/6/1 Johannes Schlüter :
>> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>>> > This variant is not workable, because there are (in the example) in 2014
>>> > *five* branches. Merging between those, manually and automatically is
>>> > going to be a major pain. I'd say we all rather want to focus our time
>>> > on fixes and new features; and not spend more time doing branch merging,
>>> > whatever tool we use for this.
>>>
>>> This is similar to my initial point about the proposal. We need to
>>> figure out a way to have fewer active bug-fix branches, just because
>>> it make dev live very difficult. Derick I am not sure your example is
>>> much better, since you still have 4 active branches (if I am reading
>>> the diagram correctly). I think 3 active bug fix branches, with maybe
>>> 1 security fixes only branches is the most we should have.
>>
>> I mentioned this before: I like the Ubuntu model:
>
>> * One development branch for the next version
>> * One current version
>> * One "long term" supported version
>
> I do not like it. It does not apply to a programming language and its
> requirement from an end user point of view.
>
> To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a
> drastic improvement for ISPs, framework developers etc.
>
> The issue about having multiple or too many branches active is a non
> problem imo. Yes, it takes a couple of hours yet to release php, but
> that's something that could be automated easily (the tasks, not the
> whole thing) . It will also be much safer to do it given that no fancy
> commits can or should be applied in patch releases/stable branches.
>
> In addition we are getting more and more automated testing and that
> will make the release processes even smoother and safer. Unlike now
> where we need months to do 5.3 patches when we should have at least .7
> already and .8 being in the work.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

hi,


2011/6/1 Johannes Schlüter :
> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>> > This variant is not workable, because there are (in the example) in 2014
>> > *five* branches. Merging between those, manually and automatically is
>> > going to be a major pain. I'd say we all rather want to focus our time
>> > on fixes and new features; and not spend more time doing branch merging,
>> > whatever tool we use for this.
>>
>> This is similar to my initial point about the proposal. We need to
>> figure out a way to have fewer active bug-fix branches, just because
>> it make dev live very difficult. Derick I am not sure your example is
>> much better, since you still have 4 active branches (if I am reading
>> the diagram correctly). I think 3 active bug fix branches, with maybe
>> 1 security fixes only branches is the most we should have.
>
> I mentioned this before: I like the Ubuntu model:

> * One development branch for the next version
> * One current version
> * One "long term" supported version

I do not like it. It does not apply to a programming language and its
requirement from an end user point of view.

To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a
drastic improvement for ISPs, framework developers etc.

The issue about having multiple or too many branches active is a non
problem imo. Yes, it takes a couple of hours yet to release php, but
that's something that could be automated easily (the tasks, not the
whole thing) . It will also be much safer to do it given that no fancy
commits can or should be applied in patch releases/stable branches.

In addition we are getting more and more automated testing and that
will make the release processes even smoother and safer. Unlike now
where we need months to do 5.3 patches when we should have at least .7
already and .8 being in the work.

Cheers,
--
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Antony Dovgal]

On 05/31/2011 10:42 PM, Brian Moon wrote:

https://wiki.php.net/rfc/shortsyntaxforarrays


I can has vote on this RFC https://wiki.php.net/rfc/shortsyntaxforfunctions ?

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Antony Dovgal]

On 06/01/2011 01:59 AM, Rasmus wrote:

Other than a couple of grumpy old-timers, I
think we are in agreement that we should add a short array syntax.


Well, thanks for calling me that!  =)

But seriously, I don't think all of these people are grumpy old-timers:


Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe
Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes
Schlüter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel
Brown, Jochem Maas, Hannes Magnusson, David Coallier


(yeah, I know some of them have changed their votes already)

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Ilia Alshanetsky]

Sounds reasonable.

2011/6/1 Johannes Schlüter :
> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>> > This variant is not workable, because there are (in the example) in 2014
>> > *five* branches. Merging between those, manually and automatically is
>> > going to be a major pain. I'd say we all rather want to focus our time
>> > on fixes and new features; and not spend more time doing branch merging,
>> > whatever tool we use for this.
>>
>> This is similar to my initial point about the proposal. We need to
>> figure out a way to have fewer active bug-fix branches, just because
>> it make dev live very difficult. Derick I am not sure your example is
>> much better, since you still have 4 active branches (if I am reading
>> the diagram correctly). I think 3 active bug fix branches, with maybe
>> 1 security fixes only branches is the most we should have.
>
> I mentioned this before: I like the Ubuntu model:
>
> * One development branch for the next version
> * One current version
> * One "long term" supported version
>
> The current version is aimed to give early access to new features, to
> avoid cases like traits which take years to come out while a bit more
> conservative users (and maybe distros) may stay on the LTS. Once a new
> "current" comes out there won't be fixes for the previous anymore.
> Every n-th "current" release will be a long term supported (LTS) release
> receiving only only only bug fixing and the older it gets the more
> critical bugs, only. What "long term" means can be discussed.
> It is open for discussion if a LTS version will directly terminate the
> previous LTS version or whether an LTS version will be released instead
> of an "current" version, so for one period there would be two LTS but no
> "current" branch.
>
> johannes
>
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Johannes Schlüter]

On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
> > This variant is not workable, because there are (in the example) in 2014
> > *five* branches. Merging between those, manually and automatically is
> > going to be a major pain. I'd say we all rather want to focus our time
> > on fixes and new features; and not spend more time doing branch merging,
> > whatever tool we use for this.
> 
> This is similar to my initial point about the proposal. We need to
> figure out a way to have fewer active bug-fix branches, just because
> it make dev live very difficult. Derick I am not sure your example is
> much better, since you still have 4 active branches (if I am reading
> the diagram correctly). I think 3 active bug fix branches, with maybe
> 1 security fixes only branches is the most we should have.

I mentioned this before: I like the Ubuntu model:

* One development branch for the next version
* One current version
* One "long term" supported version

The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS. Once a new
"current" comes out there won't be fixes for the previous anymore.
Every n-th "current" release will be a long term supported (LTS) release
receiving only only only bug fixing and the older it gets the more
critical bugs, only. What "long term" means can be discussed.
It is open for discussion if a LTS version will directly terminate the
previous LTS version or whether an LTS version will be released instead
of an "current" version, so for one period there would be two LTS but no
"current" branch.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] INF behavior

[Tjerk Anne Meesters]

On Wed, Jun 1, 2011 at 6:04 AM, Gustavo Lopes  wrote:
> On Tue, 31 May 2011 22:41:36 +0100, Hannes Landeholm 
> wrote:
>
>>> Agree with Derick, strictly speaking, in maths science, INF != INF.
>>
>> I disagree,based on quote from
>> http://compilers.iecc.com/comparch/article/98-07-134:
>>
>> "Since a projective infinity doesn't have a sign, comparing a floating
>> point value other than infinity to a projective infinity is unordered.
>> However, a projective infinity is equal to itself."
>>
>
> Yes, as I argued, for purposes of IEEE 754, it's certainly the case that INF
> = INF.
>
> This may not be true for certain meanings of "infinity" or notions of
> ordering, but we have a standard for floating point arithmetic with
> well-defined terms and rules which we ought to follow.
>
> As a curiosity, Mathematica defines the result of Equal[Infinity, Infinity]
> and Equal[Overflow, Overflow], but not for ComplexInfinity or Indeterminate
> (similar to NaN):
>
> In[1]:= ComplexInfinity == ComplexInfinity
> Out[1]= ComplexInfinity == ComplexInfinity
> In[2]:= Infinity == Infinity
> Out[2]= True
> In[3]:= Overflow == Overflow
> Out[3]= True
> In[4]:= Indeterminate == Indeterminate
> Out[4]= Indeterminate == Indeterminate

That, and the fact that "a != b" should always imply "a !== b" imo.
And if you must compare with SQL it would be something more akin to
"is_infinite(a)"

>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
--
Tjerk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

btwr, I did not mean to kill the discussions but it would be awesome
if every participant would read the past discussions about this RFC
and replies accordingly.

Yes, there are alternatives and other needs related to this RFC, but
it is really time to go with it or forget it.

Cheers,

On Wed, Jun 1, 2011 at 2:10 PM, Pierre Joye  wrote:
> can we please (please!) focus on voting on the RFC and avoid an
> enumeration of all possible syntax, formats, ideas, trolls&co we had
> in the last decade? Simply vote and let us move one.
>
> Thanks for your understanding,
>
> On Wed, Jun 1, 2011 at 2:05 PM, Marcel Esser  wrote:
>> My kneejerk reaction to this, as no one particularly important, is to not
>> allow mixing those syntaxes.
>>
>> I looked at the RFC a minute ago, and I read a reference to a parallel
>> solution to this being named parameters. Which, I think, is not accurate.
>> The problem with the array() notation is definitely at deep nesting levels.
>> The fact that arrays as arguments suddenly look nicer is basically just a
>> bonus. I really just don't want to type array() twenty-five times in the
>> same data structure.
>>
>> PS: That is not to say that I wouldn't love named parameters; I would adore
>> them. I can't count how many times I've thought that a router would benefit
>> enormously from being able to do that. However, using an array instead
>> worked fine - and that is cool.
>>
>> - M.
>>
>> On 6/1/2011 8:01 AM, Arvids Godjuks wrote:
>>>
>>> My personal feel about this is that yes, short arrays are not bad, but
>>> things like
>>>
>>> $a = new A;
>>> $a[array()];
>>>
>>> just scare the crap of me when I see them. To me PHP is easy on syntax
>>> and it's good. When I see Ruby or Python code with all it's crazy
>>> magic I feel sick. Still one day I will have to learn one, but that
>>> doesn't mean PHP should go that way too (i'm not alien to system
>>> languages, I had some practice with Pascal, Delphi&  C some years ago,
>>> just wanted to go the WEB path so migrated to PHP).
>>>
>>> If it's not too much, it would be good to avoid such strange
>>> constructs at all, because people are mean and they tend to do bad
>>> things in code.
>>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>



-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

pls add your svn handle in the right section:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote

On Wed, Jun 1, 2011 at 2:08 PM, Sebastian Bergmann  wrote:
> Am 31.05.2011 20:42, schrieb Brian Moon:
>> https://wiki.php.net/rfc/shortsyntaxforarrays
>
>  -1
>
> --
> Sebastian Bergmann                    Co-Founder and Principal Consultant
> http://sebastian-bergmann.de/                           http://thePHP.cc/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[David Soria Parra]

On 2011-05-31, Brian Moon  wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> PHP SVN account holder voters
>=
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, 
> Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe 
> Pena, Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes 
> Schl??ter, Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel 
> Brown, Jochem Maas, Hannes Magnusson, David Coallier

+1 from me now after reviewing the discussion and the patch. But I would
like to see ['x' => 2] instead of ['x': 2] as => was always reserved for
assoc in PHP (as mentioned earlier in the thread).


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Pierre Joye]

can we please (please!) focus on voting on the RFC and avoid an
enumeration of all possible syntax, formats, ideas, trolls&co we had
in the last decade? Simply vote and let us move one.

Thanks for your understanding,

On Wed, Jun 1, 2011 at 2:05 PM, Marcel Esser  wrote:
> My kneejerk reaction to this, as no one particularly important, is to not
> allow mixing those syntaxes.
>
> I looked at the RFC a minute ago, and I read a reference to a parallel
> solution to this being named parameters. Which, I think, is not accurate.
> The problem with the array() notation is definitely at deep nesting levels.
> The fact that arrays as arguments suddenly look nicer is basically just a
> bonus. I really just don't want to type array() twenty-five times in the
> same data structure.
>
> PS: That is not to say that I wouldn't love named parameters; I would adore
> them. I can't count how many times I've thought that a router would benefit
> enormously from being able to do that. However, using an array instead
> worked fine - and that is cool.
>
> - M.
>
> On 6/1/2011 8:01 AM, Arvids Godjuks wrote:
>>
>> My personal feel about this is that yes, short arrays are not bad, but
>> things like
>>
>> $a = new A;
>> $a[array()];
>>
>> just scare the crap of me when I see them. To me PHP is easy on syntax
>> and it's good. When I see Ruby or Python code with all it's crazy
>> magic I feel sick. Still one day I will have to learn one, but that
>> doesn't mean PHP should go that way too (i'm not alien to system
>> languages, I had some practice with Pascal, Delphi&  C some years ago,
>> just wanted to go the WEB path so migrated to PHP).
>>
>> If it's not too much, it would be good to avoid such strange
>> constructs at all, because people are mean and they tend to do bad
>> things in code.
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Sebastian Bergmann]

Am 31.05.2011 20:42, schrieb Brian Moon:
> https://wiki.php.net/rfc/shortsyntaxforarrays

 -1

-- 
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/   http://thePHP.cc/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Marcel Esser]

My kneejerk reaction to this, as no one particularly important, is to 
not allow mixing those syntaxes.


I looked at the RFC a minute ago, and I read a reference to a parallel 
solution to this being named parameters. Which, I think, is not 
accurate. The problem with the array() notation is definitely at deep 
nesting levels. The fact that arrays as arguments suddenly look nicer is 
basically just a bonus. I really just don't want to type array() 
twenty-five times in the same data structure.


PS: That is not to say that I wouldn't love named parameters; I would 
adore them. I can't count how many times I've thought that a router 
would benefit enormously from being able to do that. However, using an 
array instead worked fine - and that is cool.


- M.

On 6/1/2011 8:01 AM, Arvids Godjuks wrote:

My personal feel about this is that yes, short arrays are not bad, but
things like

$a = new A;
$a[array()];

just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to learn one, but that
doesn't mean PHP should go that way too (i'm not alien to system
languages, I had some practice with Pascal, Delphi&  C some years ago,
just wanted to go the WEB path so migrated to PHP).

If it's not too much, it would be good to avoid such strange
constructs at all, because people are mean and they tend to do bad
things in code.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Arvids Godjuks]

My personal feel about this is that yes, short arrays are not bad, but
things like

$a = new A;
$a[array()];

just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to learn one, but that
doesn't mean PHP should go that way too (i'm not alien to system
languages, I had some practice with Pascal, Delphi & C some years ago,
just wanted to go the WEB path so migrated to PHP).

If it's not too much, it would be good to avoid such strange
constructs at all, because people are mean and they tend to do bad
things in code.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

>>       * running the various test suites (phpt, custom real life tests,
>>       platform specific tests). Some tests need a day to run
>>   * November, Final
>>     * Last RC taken as final, golden release (no change between the last RC 
>> and the final version)
>
> TBH, I think 6 months is too much between first alpha and release.
> Because we'd only have 6 months for a "normal cycle".

That's a max and reasonable time frame based on what we had in the
past and based on discussions with the devs actually doing the work.
So what if we make it before? a wonder! But at least there is a max
deadline.


> One issue with it though, the page that lists all the RFCs isn't
> maintained, and status isn't always updated. That needs to be done
> otherwise  we get to "oh, is this implemented yet?"

help welcomes.

>> Features can use branch(es) if necessary, doing so will minimize the
>> impact of other commits and changes on the development of a specific
>> feature (or the other way 'round). The shorter release cycle also
>> ensures that a given feature can get into the next release, as long as
>> the RFC has been accepted.
>
> I would word "can use branches if necessary" stronger, like "can use
> branches if *absolutely* necessary". The reason why, is that it is a good
> idea to get as many people familiar with new code. Of course, if there
> is a lot of ongoing work then a feature branch helps, but it should be
> merged into trunk as soon as it compiles (and doesn't break any test
> case) for peer review and more testing.


do not see a reason to change this part, it is self explaining and if
a developer likes to use an extra branche, then it is up to him as he
maintains that code anyway, at least for the development period.

>> The change to what we have now is the voting process. It will not
>> happen anymore on the mailing list but in the RFCs directly, for
>> php.net members, in an anonymous way (who votes what won't be made
>> public).
>>
>> The question for this section is about who will be allowed to vote:
>>   * php-src (yes, no)
>>   * php-doc (yes, no)
>>   * qa, *phpt (yes, no)
>>   * other sub projects like pear (yes, no)
>>
>> NB: the poll plugin will be installed shortly
>
> A few things here that I don't like. First of all, I think voting
> *should* be public.

Please read the RFC.

>> = Feature(s) preview release, solving the experimental features =

> Isn't a feature preview just a snapshot or (the first) alpha?

no, and it may not be ready in time for a given release. And that
allows us to show something at any time to get more feedbacks from
users about a given complex or big feature/change without taking the
risk to break a given normal release. That sounds like a good solution
and can be done at any time.



-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Gustavo Lopes]

Em Tue, 31 May 2011 19:42:18 +0100, Brian Moon   
escreveu:



https://wiki.php.net/rfc/shortsyntaxforarrays



-1

I see very little benefit, specially in my keyboard layout, where typing [  
and ] requires pressing Alt Gr + 8/9.


Plus, it can cause confusion because [] is currently used for array  
dereference.


For instance:


http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Arvids Godjuks]

Holly crap, god save us from that.

+1 on short syntax (personally I try to avoid it in JS too - I use new
Array() or JSON), but no : please. It's just ridiculous for PHP.

2011/6/1 Patrick ALLAERT :
> 2011/5/31 Brian Moon :
>> https://wiki.php.net/rfc/shortsyntaxforarrays
>>
>> Since this was brought again recently by Rasmus
>> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
>> people including Andi chimed in on it and Ilia seemed to reverse his
>> thoughts as well (with caveats), I thought I would start a real thread about
>> it. The reason the RFC stalled was stated as:
>>
>> "This patch will not be accepted because slight majority of the core
>> developers voted against. Though if you take a accumulated mean between core
>> developers and userland votes seems to show the opposite it would be
>> irresponsible to submit a patch witch is not supported or maintained in the
>> long run."
>>
>> So, the PHP users want it, but too many PHP core devs did not want it or did
>> not see the use of it. From rereading the mailing list archive, most had the
>> tone of "I don't see a reason for it." I was in that camp in 2003 when it
>> first came up. However, with the emergence of JSON and systems that use JSON
>> as an interface, this type of syntax would be most welcome in the day to day
>> life of a PHP developer.
>>
>> I would prefer (as Rasmus pointed out) not to start a long discussion about
>> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
>> page) below would like to change your vote or if you are not listed below
>> and would like to be counted, that would be great too.
>>
>> PHP SVN account holder voters
>> =
>> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
>> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>>
>> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
>> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
>> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
>> Maas, Hannes Magnusson, David Coallier
>>
>>
>> Other voters
>> 
>> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
>> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
>> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
>> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>>
>> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>>
>>
>> --
>> Brian.
>> http://brian.moonspot.net
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> @Zend
>
> Suggestion for the Zend PHP 5.4 Certification:
> Which of the following constructs are valid:
> $array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
> $array = [3 => [42], 'foo': array( 'orange' : 'juice'), 'bar' : 'apple'];
> $array = [[3] => 42, 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
> {$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];}
>
> :)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

On Wed, Jun 1, 2011 at 1:45 PM, Ilia Alshanetsky  wrote:
>> This variant is not workable, because there are (in the example) in 2014
>> *five* branches. Merging between those, manually and automatically is
>> going to be a major pain. I'd say we all rather want to focus our time
>> on fixes and new features; and not spend more time doing branch merging,
>> whatever tool we use for this.
>
> This is similar to my initial point about the proposal. We need to
> figure out a way to have fewer active bug-fix branches, just because
> it make dev live very difficult. Derick I am not sure your example is
> much better, since you still have 4 active branches (if I am reading
> the diagram correctly). I think 3 active bug fix branches, with maybe
> 1 security fixes only branches is the most we should have.

yes, and we can adapt that in time and when necessary.

The core of this RFC however is still valid and is a very good step
forward for our project (that's for Derick's reply).

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Ilia Alshanetsky]

> This variant is not workable, because there are (in the example) in 2014
> *five* branches. Merging between those, manually and automatically is
> going to be a major pain. I'd say we all rather want to focus our time
> on fixes and new features; and not spend more time doing branch merging,
> whatever tool we use for this.

This is similar to my initial point about the proposal. We need to
figure out a way to have fewer active bug-fix branches, just because
it make dev live very difficult. Derick I am not sure your example is
much better, since you still have 4 active branches (if I am reading
the diagram correctly). I think 3 active bug fix branches, with maybe
1 security fixes only branches is the most we should have.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Patrick ALLAERT]

2011/5/31 Brian Moon :
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core
> developers voted against. Though if you take a accumulated mean between core
> developers and userland votes seems to show the opposite it would be
> irresponsible to submit a patch witch is not supported or maintained in the
> long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or did
> not see the use of it. From rereading the mailing list archive, most had the
> tone of "I don't see a reason for it." I was in that camp in 2003 when it
> first came up. However, with the emergence of JSON and systems that use JSON
> as an interface, this type of syntax would be most welcome in the day to day
> life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
> page) below would like to change your vote or if you are not listed below
> and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
> Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> 
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>
> --
> Brian.
> http://brian.moonspot.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

@Zend

Suggestion for the Zend PHP 5.4 Certification:
Which of the following constructs are valid:
$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
$array = [3 => [42], 'foo': array( 'orange' : 'juice'), 'bar' : 'apple'];
$array = [[3] => 42, 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];
{$array = [3 => [42], 'foo': array( 'orange' => 'juice'), 'bar' => 'apple'];}

:)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Derick Rethans]

On Wed, 1 Jun 2011, Etienne Kneuss wrote:

> +1 for a short array syntax.

I'm still -1 on it. It makes absolutely unreadable code (yes, also in 
JavaScript with f.e. MongoDB).

> But only if you keep it consistent, PHP has always been using => for
> key/val association, I don't see any reason to suddenly provide "key":
> "val", unless what you want is to confuse people.

Yes, definitely "=>" vs. ":" in any case.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Derick Rethans]

On Wed, 1 Jun 2011, Internals wrote:

> URL: https://wiki.php.net/rfc/releaseprocess

Comments again-they are mostly similar as before-I was quite annoyed 
that I didn't even get feedback on when I sent it last time:

>  Example time line with two majors versions  
> However it could happen that a new major version is desired while the
> active major version is still heavily used. Like what we had between
> php 4 and 5 or for the oldest, between php 3 and 4.

Because of this, Perhaps the latest release before a new major one
should run for a year longer. So in the example above, 5.6 runs until
where 6.0 ends too.


> 
>  pre release phase
>  release lifetime bugs
>  release lifetime security only
> DEOL
> Version Time ->
>20112012   2013 201420152016   
>  2017
> | | | | | | | | | | | |   
>   |
> 5.3 +-D
> 5.4 |*+---D | | | |   
>   | 
> 5.5 | | |**---D | |   
>   |
> 5.6 | | |   |**---D
> 6.0 | | |**---D | |
> 6.1 | | |   |**---D
> 

This variant is not workable, because there are (in the example) in 2014
*five* branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
whatever tool we use for this.

I prefer the other one that was suggested before:

>  Example time line with only one major version at a time  
> 
>  pre release phase
>  release lifetime with all bugs fixes, no feature addition
>  release lifetime security  fixes only
> DEOL
> Version Time ->
>20112012   2013 201420152016   
>  2017
> | | | | | | | | | | | |   
>   |
> 5.3 +-D
> 5.4 |*+---D
> 5.5 | | |**---D
> 5.6 | | | | |**---D
> 6.0 | | | | 
> |**---D
> 6.1 | | | | 
> |**---D
> 



>  Timeline example for a release 
> 
> 
>   * June
> * Decisions which features or changes will be in the next release
> * 1st release alpha (may have many alpha)
>   * At least one release per month, more at wish
>   * Septempber, RC phases, biweekly release
> * each RC should go through the QA before being published
>   * usually2 days

Uh? The whole RC phase is QA. I don't see why you need another QA
'period'.

I would however want to say that packaging and bundling is
done on Wednesday, with any release on Thursday (morning). The original
idea was to not have just a Friday for people to upgrade before a
weekend. I've always bundled/packages on Wednesday and released on
Thursday, but I've seen that lately it's all done on Thursday, and
sometimes even Thursday evening US time.

>   * running the various test suites (phpt, custom real life tests,
>   platform specific tests). Some tests need a day to run
>   * November, Final
> * Last RC taken as final, golden release (no change between the last RC 
> and the final version)

TBH, I think 6 months is too much between first alpha and release.
Because we'd only have 6 months for a "normal cycle".

> = Feature selection and development =
> 
> RFCs have been introduced two years ago and have been proven as being
> an amazing way to avoid conflicts while providing a very good way to
> propose new things to php.net. New features or additions to the core
> should go through the RFC process.

New big language features, I agree with. Small little self-contained
extension functions do not need a full blown RFC process. Extension's
maintainers should have the responsibilty for this. (I am not saying it
wouldn't be good to have an RFC for some of those new additions though).

> It has been done successfully (as
> the process went well, but the features were not necessary accepted)
> already for a dozen of new features or improvements.

One issue with it though, the page that lists all the RFCs isn't
maintained, and status isn't always updated. That needs to be done
otherwise  we get to "oh, is this implemented yet?"

> Features can use branch(es) if necessary, doing so will minimize the
> impact of other commits and changes on the development of a specific
> feature (or the other way 'round). The shorter release cycle also
> ensures that a given feature can get into the next release, as

RE: [PHP-DEV] Final version, RFC release process

[John Crenshaw]

That isn't measurable, so it is a suggestion, not a standard. It also creates 
serious problems in userland if APIs change. API changes lead hosts to 
literally take years to update to new versions of PHP, for fear of breaking the 
sites that host with them. What about:

Userland API compatibility of documented interfaces and behaviors must be kept. 
API internals should be backwards compatible wherever possible.

This relaxes the userland restriction just slightly to allow for changes that 
break undocumented behaviors, but leaves it basically stable and measurable. 
This also leaves the door open for internal changes if they're really needed, 
but basically suggests against it.

John Crenshaw
Priacta, Inc.

-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com] 
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] Final version, RFC release process

Hi,

In my opinion a restriction "API compatibility must be kept (internals 
and userland)" for x.y.z to x.y+1.z is too strict. It just can block 
some new features forever.

I would suggest to change "API compatibility must be kept" to "API 
backward compatibility must be kept as much as possible".

Thanks. Dmitry.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

On Wed, Jun 1, 2011 at 1:12 PM, Pierre Joye  wrote:
> hi,
>
> On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov  wrote:
>> Hi,
>>
>> In my opinion a restriction "API compatibility must be kept (internals and
>> userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
>> features forever.
>
> btw, new APIs do not break API or API.

I mean API or ABI.

> I do not think we should allow BC breaks between x.y and x.y+1. That's
> counter productive and prevent users to migrate easily and quicker.
> That's the whole point of having more frequent releases.

We could allow BC break internally, using your wording, but that's
something I do not like either.



-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Pierre Joye]

hi,

On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov  wrote:
> Hi,
>
> In my opinion a restriction "API compatibility must be kept (internals and
> userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
> features forever.

btw, new APIs do not break API or API.

I do not think we should allow BC breaks between x.y and x.y+1. That's
counter productive and prevent users to migrate easily and quicker.
That's the whole point of having more frequent releases.


Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final version, RFC release process

[Dmitry Stogov]

Hi,

In my opinion a restriction "API compatibility must be kept (internals 
and userland)" for x.y.z to x.y+1.z is too strict. It just can block 
some new features forever.


I would suggest to change "API compatibility must be kept" to "API 
backward compatibility must be kept as much as possible".


Thanks. Dmitry.


On 06/01/2011 02:09 PM, Pierre Joye wrote:

Hi,

Long due but finally sending the final RFC for the release process.

There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.

URL: https://wiki.php.net/rfc/releaseprocess

In parallel to the current discussions about 5.4's features, let get
this RFC approved and use right away for 5.3 (to define its life time)
and 5.4. That will spare us the issues we had in the past with 5.3,
for example and ensure that we get 5.4 release in a reasonable
timeframe and without endless delays, or features additions.

It is important to keep in mind that this RFC is not written in stone
but it is a good base to begin with. We can always adapt it later, if
necessary.

https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add
your svn id. Proposers do not need to do it as they are indeed there
as +1 already (I added myself as example)

Cheers,
--
Pierre

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




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[John Crenshaw]

Using an explicit json_decode is actually a huge problem. It isn't just hard to 
write encoded stuff into strings, it is a security issue because you have to 
encode the values that you are then encoding into JSON. For example:

json_decode('{a: "a", b: "b", foo: "'.$_POST['foo'].'"}'); // !!! Security 
problem !!! Value injection is possible with a properly formed 'foo' parameter 
in the post.

To avoid this, you have to do the following:
json_decode('{a: "a", b: "b", foo: '. json_encode($_POST['foo'].'}');

Compare that clunky monstrosity to:
{a: "a", b: "b", foo: $_POST['foo']};

Remember that this syntax is less about constants and more about binding values 
into some structure.

As a C++ programmer I whole heartedly agree with the confusion point, but as a 
PHP developer I don't. Basically every PHP developer is going to be familiar 
with JavaScript, because it is also a web language. Go to oDesk.com, and you 
can't find a developer looking for PHP work who doesn't know how to work with 
jQuery or similar. Browser fragmentation makes jQuery or something similar 
almost essential for modern web development, and JSON is used extensively in 
all of these frameworks. Any PHP developer worth a dime will know exactly what 
they are looking at.

I agree that [a: 'b'] would be totally wrong. This doesn't look like PHP OR 
JSON, and is likely to cause confusion. If [a=>$b] is the only syntax people 
can agree on, I can live with that, but IMO that syntax will actually create 
MORE confusion than just allowing pure JSON (opinion informed by trying to get 
new devs up to speed on a project that uses MongoDB.)

John Crenshaw
Priacta, Inc.

-Original Message-
From: dukeofgaming [mailto:dukeofgam...@gmail.com] 
Sent: Wednesday, June 01, 2011 5:51 AM
To: Ford, Mike
Cc: Etienne Kneuss; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

After that argument, I think I'm against ":" now too. +1 to "=>"

Could "{ }" be implemented for objects too then?.

Regards,

David

On Wed, Jun 1, 2011 at 4:36 AM, Ford, Mike  wrote:

> > -Original Message-
> > From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
> > Etienne Kneuss
> > Sent: 01 June 2011 01:57
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
> >
> > +1 for a short array syntax.
> >
> > But only if you keep it consistent, PHP has always been using => for
> > key/val association, I don't see any reason to suddenly provide
> > "key":
> > "val", unless what you want is to confuse people.
>
> Hear, hear and hear, hear to that!
>
> ['a': 'b'] just feels completely un-PHP-like, and I'd be totally
> against it.
>
> If the desire is to have a "native" JSON syntax so that you can eval()
> imported JSON, then I'm completely anti that, too -- that's a case
> where I'd far rather be explicit and use json_decode(). And since, no
> matter how you slice it, you're never going to get a complete fit
> between native PHP structures and JSON encoding, I don't believe you
> should even try.
>
> I just can't see the problem with saying: PHP arrays (and maybe
> objects?) look like *this*, and if you want to import/export them
> from/to a JSON representation, there are functions to do it like
> *this*. This seems to be the perfectly sensible approach of other
> languages I've used recently (although my perl is somewhat out-of-date,
> and my python even more out-of-daterer and minimal at that!). Even
> ECMAScript is going down the route of explicit conversion with
> JSON.parse() and JSON.stringify() in ECMAScript 5!
>
> All in all, still +1 for [1, 2=>2, 'a'=>'b'], and -several million (for
> style) for any syntax involving colons.
>
> Cheers!
>
> Mike
>  --
> Mike Ford,
> Electronic Information Developer, Libraries and Learning Innovation,
> Leeds Metropolitan University, C507 City Campus,
> Portland Way, LEEDS,  LS1 3HE,  United Kingdom
> E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
>
>
>
>
>
>
> To view the terms under which this email is distributed, please go to
> http://disclaimer.leedsmet.ac.uk/email.htm
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Final version, RFC release process

[Pierre Joye]

Hi,

Long due but finally sending the final RFC for the release process.

There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.

URL: https://wiki.php.net/rfc/releaseprocess

In parallel to the current discussions about 5.4's features, let get
this RFC approved and use right away for 5.3 (to define its life time)
and 5.4. That will spare us the issues we had in the past with 5.3,
for example and ensure that we get 5.4 release in a reasonable
timeframe and without endless delays, or features additions.

It is important to keep in mind that this RFC is not written in stone
but it is a good base to begin with. We can always adapt it later, if
necessary.

https://wiki.php.net/rfc/releaseprocess/vote for the votes, pls add
your svn id. Proposers do not need to do it as they are indeed there
as +1 already (I added myself as example)

Cheers,
--
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Rune Kaagaard]

Big +1 on the patch. The ":" although a better choice would be
asymmetric to how its done inside array().

On Wed, Jun 1, 2011 at 11:50 AM, dukeofgaming  wrote:
> After that argument, I think I'm against ":" now too. +1 to "=>"
>
> Could "{ }" be implemented for objects too then?.
>
> Regards,
>
> David
>
> On Wed, Jun 1, 2011 at 4:36 AM, Ford, Mike  wrote:
>
>> > -Original Message-
>> > From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
>> > Etienne Kneuss
>> > Sent: 01 June 2011 01:57
>> > To: internals@lists.php.net
>> > Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
>> >
>> > +1 for a short array syntax.
>> >
>> > But only if you keep it consistent, PHP has always been using => for
>> > key/val association, I don't see any reason to suddenly provide
>> > "key":
>> > "val", unless what you want is to confuse people.
>>
>> Hear, hear and hear, hear to that!
>>
>> ['a': 'b'] just feels completely un-PHP-like, and I'd be totally
>> against it.
>>
>> If the desire is to have a "native" JSON syntax so that you can eval()
>> imported JSON, then I'm completely anti that, too -- that's a case
>> where I'd far rather be explicit and use json_decode(). And since, no
>> matter how you slice it, you're never going to get a complete fit
>> between native PHP structures and JSON encoding, I don't believe you
>> should even try.
>>
>> I just can't see the problem with saying: PHP arrays (and maybe
>> objects?) look like *this*, and if you want to import/export them
>> from/to a JSON representation, there are functions to do it like
>> *this*. This seems to be the perfectly sensible approach of other
>> languages I've used recently (although my perl is somewhat out-of-date,
>> and my python even more out-of-daterer and minimal at that!). Even
>> ECMAScript is going down the route of explicit conversion with
>> JSON.parse() and JSON.stringify() in ECMAScript 5!
>>
>> All in all, still +1 for [1, 2=>2, 'a'=>'b'], and -several million (for
>> style) for any syntax involving colons.
>>
>> Cheers!
>>
>> Mike
>>  --
>> Mike Ford,
>> Electronic Information Developer, Libraries and Learning Innovation,
>> Leeds Metropolitan University, C507 City Campus,
>> Portland Way, LEEDS,  LS1 3HE,  United Kingdom
>> E: m.f...@leedsmet.ac.uk     T: +44 113 812 4730
>>
>>
>>
>>
>>
>>
>> To view the terms under which this email is distributed, please go to
>> http://disclaimer.leedsmet.ac.uk/email.htm
>>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[dukeofgaming]

After that argument, I think I'm against ":" now too. +1 to "=>"

Could "{ }" be implemented for objects too then?.

Regards,

David

On Wed, Jun 1, 2011 at 4:36 AM, Ford, Mike  wrote:

> > -Original Message-
> > From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
> > Etienne Kneuss
> > Sent: 01 June 2011 01:57
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
> >
> > +1 for a short array syntax.
> >
> > But only if you keep it consistent, PHP has always been using => for
> > key/val association, I don't see any reason to suddenly provide
> > "key":
> > "val", unless what you want is to confuse people.
>
> Hear, hear and hear, hear to that!
>
> ['a': 'b'] just feels completely un-PHP-like, and I'd be totally
> against it.
>
> If the desire is to have a "native" JSON syntax so that you can eval()
> imported JSON, then I'm completely anti that, too -- that's a case
> where I'd far rather be explicit and use json_decode(). And since, no
> matter how you slice it, you're never going to get a complete fit
> between native PHP structures and JSON encoding, I don't believe you
> should even try.
>
> I just can't see the problem with saying: PHP arrays (and maybe
> objects?) look like *this*, and if you want to import/export them
> from/to a JSON representation, there are functions to do it like
> *this*. This seems to be the perfectly sensible approach of other
> languages I've used recently (although my perl is somewhat out-of-date,
> and my python even more out-of-daterer and minimal at that!). Even
> ECMAScript is going down the route of explicit conversion with
> JSON.parse() and JSON.stringify() in ECMAScript 5!
>
> All in all, still +1 for [1, 2=>2, 'a'=>'b'], and -several million (for
> style) for any syntax involving colons.
>
> Cheers!
>
> Mike
>  --
> Mike Ford,
> Electronic Information Developer, Libraries and Learning Innovation,
> Leeds Metropolitan University, C507 City Campus,
> Portland Way, LEEDS,  LS1 3HE,  United Kingdom
> E: m.f...@leedsmet.ac.uk T: +44 113 812 4730
>
>
>
>
>
>
> To view the terms under which this email is distributed, please go to
> http://disclaimer.leedsmet.ac.uk/email.htm
>

RE: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)

[Ford, Mike]

> -Original Message-
> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
> Etienne Kneuss
> Sent: 01 June 2011 01:57
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
> 
> +1 for a short array syntax.
> 
> But only if you keep it consistent, PHP has always been using => for
> key/val association, I don't see any reason to suddenly provide
> "key":
> "val", unless what you want is to confuse people.

Hear, hear and hear, hear to that!

['a': 'b'] just feels completely un-PHP-like, and I'd be totally
against it.

If the desire is to have a "native" JSON syntax so that you can eval()
imported JSON, then I'm completely anti that, too -- that's a case
where I'd far rather be explicit and use json_decode(). And since, no
matter how you slice it, you're never going to get a complete fit
between native PHP structures and JSON encoding, I don't believe you
should even try.

I just can't see the problem with saying: PHP arrays (and maybe
objects?) look like *this*, and if you want to import/export them
from/to a JSON representation, there are functions to do it like
*this*. This seems to be the perfectly sensible approach of other
languages I've used recently (although my perl is somewhat out-of-date,
and my python even more out-of-daterer and minimal at that!). Even
ECMAScript is going down the route of explicit conversion with
JSON.parse() and JSON.stringify() in ECMAScript 5!

All in all, still +1 for [1, 2=>2, 'a'=>'b'], and -several million (for
style) for any syntax involving colons.

Cheers!

Mike
 -- 
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,  
Leeds Metropolitan University, C507 City Campus, 
Portland Way, LEEDS,  LS1 3HE,  United Kingdom 
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730






To view the terms under which this email is distributed, please go to 
http://disclaimer.leedsmet.ac.uk/email.htm

Re: [PHP-DEV] DVCS

[Lester Caine]

dukeofgaming wrote:

I know it will be a while until any choice of DVCS is adopted by PHP,
but I'll be creating an RFC as soon as I can edit the wiki (I can edit
the rfc namespace but cannot edit the rfc page itself to add the entry)
so that we can start making note of the current challenges and choices.


http://lsces.co.uk/wiki/index.php?page=DVCS+adoption+notes is getting rather 
long in the tooth and I need to rework my own implementation notes as a number 
of things have changed.


http://lsces.co.uk/hg/ will have all of my PHP base added soon, but recursion 
into projects is still a 'todo' here, so http://lsces.co.uk/hg/bitweaver2/ is 
not linking properly and at some point hopefully it WILL drill down to smarty, 
adodb, ckeditor, and the javascript libraries ...


The principles are fine, the mechanics still need to be completed ... and all of 
THAT is detracting from writing the PHP code which pays the bills :(


--
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Ferenc Kovacs]

On Tue, May 31, 2011 at 8:42 PM, Brian Moon  wrote:

> https://wiki.php.net/rfc/shortsyntaxforarrays
>
>
+1 for the current patch.

Tyrael

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Patrick ALLAERT]

2011/5/31 Brian Moon :
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core
> developers voted against. Though if you take a accumulated mean between core
> developers and userland votes seems to show the opposite it would be
> irresponsible to submit a patch witch is not supported or maintained in the
> long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or did
> not see the use of it. From rereading the mailing list archive, most had the
> tone of "I don't see a reason for it." I was in that camp in 2003 when it
> first came up. However, with the emergence of JSON and systems that use JSON
> as an interface, this type of syntax would be most welcome in the day to day
> life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
> page) below would like to change your vote or if you are not listed below
> and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic

+1 (patrickallaert)
I wasn't present during 1st vote.

> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
> Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> 
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>
> --
> Brian.
> http://brian.moonspot.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DVCS

[dukeofgaming]

On Wed, Jun 1, 2011 at 3:24 AM, Lester Caine  wrote:

> dukeofgaming wrote:
>
>>hggit + Mercurial Eclipse + Eclipse means I could not care less what
>>the target is EXCEPT that one can't write a project that is JUST the
>>set of sub-modules that you want to pull together. IDEALLY - both
>>GIT and HG would just pull stuff from which ever is providing a
>>particular library? So say Smarty could be on one while ADOdb is on
>>the other ... The core PHP code does not need to be so distributed,
>>but being able to pull PECL modules from a number of sources to add
>>to a core clone of the code could be useful?
>>
>> Perhaps, it would depend how teams are structured, but even it was a
>> single repository for everything I think stuff would work fine.
>>
>> My opinion is that the reason behind sub-repositories is to include code
>> from vendors, not that much to modularize development of a single big
>> project, why?, because of the distributed nature of a DVCS: imagine that
>> there is a PECL team, and that team makes a fork of the main PHP
>> repository, and they focus on that "fork" (every separate repository can
>> be regarded as a fork) and they handle all their work integration, and
>> then someone (after an ammount of work is done) pulls back from the main
>> repo (the one where last integrations are agreed to be added, "central"
>> if you must call it that) to ensure everything still runs ok, and then
>> ask to the final integrator to pull and merge their work: done.
>>
> I think this is the MAIN problem with DVCS currently ...
> Most of the 'big guns' that are pushing git are ONLY working on a single
> repository with a single set of code ( although GNOME and KDE should
> probably be 'subrepos' of the linux core project? ). The core PHP code can
> probably be handled as a single repo, but then you have to clone everything,
> including all extensions, while just being able to pick and choose would be
> nice.


True, that would be a very big clone.


>
>  Oh, and HG supports svn and git as subrepos now.
>>
> It is coming along ... I'm currently following a discussion on getting this
> working properly on the mercurial list ... just which directory path should
> you be using to link things together ...
>
>
I know it will be a while until any choice of DVCS is adopted by PHP, but
I'll be creating an RFC as soon as I can edit the wiki (I can edit the rfc
namespace but cannot edit the rfc page itself to add the entry) so that we
can start making note of the current challenges and choices.

Regards,

David

Re: [PHP-DEV] DVCS

[Lester Caine]

dukeofgaming wrote:

hggit + Mercurial Eclipse + Eclipse means I could not care less what
the target is EXCEPT that one can't write a project that is JUST the
set of sub-modules that you want to pull together. IDEALLY - both
GIT and HG would just pull stuff from which ever is providing a
particular library? So say Smarty could be on one while ADOdb is on
the other ... The core PHP code does not need to be so distributed,
but being able to pull PECL modules from a number of sources to add
to a core clone of the code could be useful?

Perhaps, it would depend how teams are structured, but even it was a
single repository for everything I think stuff would work fine.

My opinion is that the reason behind sub-repositories is to include code
from vendors, not that much to modularize development of a single big
project, why?, because of the distributed nature of a DVCS: imagine that
there is a PECL team, and that team makes a fork of the main PHP
repository, and they focus on that "fork" (every separate repository can
be regarded as a fork) and they handle all their work integration, and
then someone (after an ammount of work is done) pulls back from the main
repo (the one where last integrations are agreed to be added, "central"
if you must call it that) to ensure everything still runs ok, and then
ask to the final integrator to pull and merge their work: done.

I think this is the MAIN problem with DVCS currently ...
Most of the 'big guns' that are pushing git are ONLY working on a single 
repository with a single set of code ( although GNOME and KDE should probably be 
'subrepos' of the linux core project? ). The core PHP code can probably be 
handled as a single repo, but then you have to clone everything, including all 
extensions, while just being able to pick and choose would be nice. Moving to 
userland ... being able to follow the latest Smarty, ADOdb and other libraries 
in parallel with one's own code base is somewhat useful ... and something I've 
actually been doing in Eclipse already for several years. DVCS has currently 
distorted the picture because it simply does not integrate well yet :( Adopting 
one path for the core code but needing a different one for working with it just 
seems wrong to me, so sitting on the fence for the moment seems right. I'm 
actively using HG - but the masters I am working into are on github so sitting 
on the fence is not a problem :)



Oh, and HG supports svn and git as subrepos now.
It is coming along ... I'm currently following a discussion on getting this 
working properly on the mercurial list ... just which directory path should you 
be using to link things together ...


--
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)

[Peter Cowburn]

+1 from me to *any* of the short-form suggestions (JSON or otherwise).

On 31 May 2011 19:42, Brian Moon  wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with caveats), I thought I would start a real thread about
> it. The reason the RFC stalled was stated as:
>
> "This patch will not be accepted because slight majority of the core
> developers voted against. Though if you take a accumulated mean between core
> developers and userland votes seems to show the opposite it would be
> irresponsible to submit a patch witch is not supported or maintained in the
> long run."
>
> So, the PHP users want it, but too many PHP core devs did not want it or did
> not see the use of it. From rereading the mailing list archive, most had the
> tone of "I don't see a reason for it." I was in that camp in 2003 when it
> first came up. However, with the emergence of JSON and systems that use JSON
> as an interface, this type of syntax would be most welcome in the day to day
> life of a PHP developer.
>
> I would prefer (as Rasmus pointed out) not to start a long discussion about
> it. Primarily I would be curious if anyone on the lists (from the RFC wiki
> page) below would like to change your vote or if you are not listed below
> and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
> Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
> Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown, Jochem
> Maas, Hannes Magnusson, David Coallier
>
>
> Other voters
> 
> Pro: Sebastian Deutsch, Ryusuke Sekiyama, Stefan Marr, Alexey Zakhlestin,
> Carl P. Corliss, Darius Jahandarie, Giedrius D, Eric Coleman, Max Antonov,
> Mike Ford, Larry Garfield, Sam Barrow, Taylor Luk, Hans Ahlin, Karoly
> Negyesi, Guilherme Blanco, Jonathan-Bond Caron
>
> Contra: Geoffrey Sneddon, Tomi Kaistila, David Zühlke
>
>
> --
> Brian.
> http://brian.moonspot.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DVCS

[dukeofgaming]

On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine  wrote:

> Drak wrote:
>
>>At the current time I think that PHP would need to restructure how
>>it is packaged up to provide a single repo in both HG or GIT.
>>Keeping SVN ( I'd still prefer CVS here it works BETTER as a master
>>for DVCS! ) as the master from which we CAN currently sync using HG
>>or GIT is the best of a bad job currently. Unless some knows better
>>
>> I know what you mean.  There are solutions like submodules in GIT but it
>> does require some small restructuring usually.  By the way, TortoiseGIT
>> is now quite excellent for Windows GUI.  A new version 1.7.0 is just
>> about to be released too.  I'm a bit biased against GIT but overall, GIT
>> is getting way more traction than Hg and github.com 
>>
>> excels in features compared to anything else.
>>
> When TortoiseGIT runs in Linux as well - they will have caught up!
> TortoiseHg works transparently in both and on Mac I believe. My customer
> base is mainly windows biased while I've been running on Linux here for some
> years now. I need both platforms to do the same thing - which Eclipse has
> provided for several years, but the DVCS camps still need to address.
> Windows GIT is something different from Linux GIT at the moment - which is
> probably all that is putting me off it. Actually when I was forced to used
> GIT the windows side simply did not work at all, so I HAD to use hggit to
> get anything!
>
>
>   From what I have seen also, IDE integration with GIT is starting to
>> catchup both in NetBeans and Eclipse - and already way ahead of the pack
>> is phpStorm for VCS integration, but it's not free.
>>
> hggit + Mercurial Eclipse + Eclipse means I could not care less what the
> target is EXCEPT that one can't write a project that is JUST the set of
> sub-modules that you want to pull together. IDEALLY - both GIT and HG would
> just pull stuff from which ever is providing a particular library? So say
> Smarty could be on one while ADOdb is on the other ... The core PHP code
> does not need to be so distributed, but being able to pull PECL modules from
> a number of sources to add to a core clone of the code could be useful?
>
>
Perhaps, it would depend how teams are structured, but even it was a single
repository for everything I think stuff would work fine.

My opinion is that the reason behind sub-repositories is to include code
from vendors, not that much to modularize development of a single big
project, why?, because of the distributed nature of a DVCS: imagine that
there is a PECL team, and that team makes a fork of the main PHP repository,
and they focus on that "fork" (every separate repository can be regarded as
a fork) and they handle all their work integration, and then someone (after
an ammount of work is done) pulls back from the main repo (the one where
last integrations are agreed to be added, "central" if you must call it
that) to ensure everything still runs ok, and then ask to the final
integrator to pull and merge their work: done.

Oh, and HG supports svn and git as subrepos now.

Regards,

David

Re: [PHP-DEV] Wiki editing privileges

[dukeofgaming]

Hmm, I can edit pages within the RFC namespace but I cannot edit
https://wiki.php.net/rfc.

Regards,

David

On Wed, Jun 1, 2011 at 1:38 AM, dukeofgaming  wrote:

> Thanks, I also don't think that was the case.
>
> Regards,
>
> David
>
>
> On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson  wrote:
>
>>
>> On May 31, 2011, at 11:05 PM, dukeofgaming wrote:
>>
>> > Hi,
>> >
>> > I remember having wiki editing privileges not so long ago, I was going
>> to
>> > enter and add the entry for discussions at
>> > https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit
>> anymore.
>> > Would it be too much to ask to have them enabled?.
>>
>> I don't think anyone [intentionally] took away wiki editing rights, but
>> you now have full access to the rfc namespace.
>>
>> Regards,
>> Philip
>>
>>
>

Re: [PHP-DEV] DVCS

[Lester Caine]

Drak wrote:

At the current time I think that PHP would need to restructure how
it is packaged up to provide a single repo in both HG or GIT.
Keeping SVN ( I'd still prefer CVS here it works BETTER as a master
for DVCS! ) as the master from which we CAN currently sync using HG
or GIT is the best of a bad job currently. Unless some knows better

I know what you mean.  There are solutions like submodules in GIT but it
does require some small restructuring usually.  By the way, TortoiseGIT
is now quite excellent for Windows GUI.  A new version 1.7.0 is just
about to be released too.  I'm a bit biased against GIT but overall, GIT
is getting way more traction than Hg and github.com 
excels in features compared to anything else.

When TortoiseGIT runs in Linux as well - they will have caught up!
TortoiseHg works transparently in both and on Mac I believe. My customer base is 
mainly windows biased while I've been running on Linux here for some years now. 
I need both platforms to do the same thing - which Eclipse has provided for 
several years, but the DVCS camps still need to address. Windows GIT is 
something different from Linux GIT at the moment - which is probably all that is 
putting me off it. Actually when I was forced to used GIT the windows side 
simply did not work at all, so I HAD to use hggit to get anything!



 From what I have seen also, IDE integration with GIT is starting to
catchup both in NetBeans and Eclipse - and already way ahead of the pack
is phpStorm for VCS integration, but it's not free.
hggit + Mercurial Eclipse + Eclipse means I could not care less what the target 
is EXCEPT that one can't write a project that is JUST the set of sub-modules 
that you want to pull together. IDEALLY - both GIT and HG would just pull stuff 
from which ever is providing a particular library? So say Smarty could be on one 
while ADOdb is on the other ... The core PHP code does not need to be so 
distributed, but being able to pull PECL modules from a number of sources to add 
to a core clone of the code could be useful?


--
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DVCS

[dukeofgaming]

Hi Lester,

AFAIK both mercurial and git support sub-repositories nicely now:

http://mercurial.selenic.com/wiki/Subrepository
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html

Regarding the graphical tools, I don't use them that much, but I see your
point. Personally, I just occasionally use the Netbeans integration because
it is easier to commit files in separate directories, but that is pretty
much it since I think the rest is easier and quicker to do with the console,
but I guess it will always be a matter of personal preference.

I've been working with hg subrepos and they are quite nice. I'm still not
that familiar with git submodules.

BTW, you don't need to use python to customize/extend mercurial's behavior,
you can use hooks: http://mercurial.selenic.com/wiki/Hook

Best regards,

David

On Wed, Jun 1, 2011 at 1:56 AM, Lester Caine  wrote:

> dukeofgaming wrote:
>
>> I thought it might be interesting for all to read some feedback I got
>> from some questions I made to the Joomla community, specifically, the
>> guys and gals that have been implementing the decoupling of the Joomla
>> framework: the Joomla Platform.
>>
>> They currently still use svn officially but they have been experimenting
>> with both mercurial and git. These are their responses so far:
>>
>>
>> http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/fd3b0151cc215c0e
>>
>> It may bring some insight to what a DVCS could do for the PHP community.
>>
>
> I think that there are perhaps still a couple of separate problems here
> which the DVCS community need to get behind for any of them to become a
> 'front runner'.
>
> The main problem here IS 'subrepo' which is a concept that neither HG or
> GIT handle particularly well, but to my mind is essential for a very much
> modular project like PHP! While I have sort of managed to put together a
> 'checkout' of a set of packages which together make a single build of the
> target project, I'm still having to pull and commit changes manually to each
> subrepo - I don't get the simple overview of outstanding changes that was SO
> nice to work with in CVS! To try and put this in a 'PHP' context ... I DID
> have a list of extensions I was working with, and a 'sync' in ECLIPSE gave
> me a nice list of which ones had had changes pushed ... I could then go and
> either simply update to those changes on an extension by extension basis -
> or review the changes in each file so allow me to integrate other peoples
> changes with my own local 'tweaks'. This is something that DVCS SHOULD be
> perfect for, but the management tools for bundling a selection of parts of a
> project are not there yet, mainly because the core developers on both HG and
> GIT "don't see then need because they don't need that type of working"!
>

> I'm limping along with HG at the moment simply because it works on both
> Linux AND Windows, while GIT's windows support is still rather hit and miss
> when one is already using other unix tools on windows, but I do not have the
> same level of integration in Eclipse that CVS and SVN provide beautify
> straight out of the box. At least I can drop out of Eclipse into TortoiseHg
> and do the code management, but it's not an ideal way of working.
>
> If I was a 'console jockey' then much of this would probably be a lot less
> of a problem. One seems to need to write scripts to do what YOU want to do
> in both HG and GIT - and then need to learn Python to do that in HG :( But I
> never used CVS from the command line so a LOT of the reasoning for even the
> switch to SVN was irrelevant since Eclipse had already solved all of those
> 'problems'.
>
> At the current time I think that PHP would need to restructure how it is
> packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd
> still prefer CVS here it works BETTER as a master for DVCS! ) as the master
> from which we CAN currently sync using HG or GIT is the best of a bad job
> currently. Unless some knows better?
>
>
> --
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>