Re: [PHP-DEV] break/continue $var
the proposed patch (backport from php6) is attached.
I think this feature is completely useless and it was agreed to remove
it about 5 years ago.
Derick, can I commit the patch today?
Thanks. Dmitry.
Dmitry Stogov wrote:
Hi,
Previously we decided to remove break/continue $var syntax.
I even implemented it in PHP6 brunch, however it wasn't backported into
trunk. Could I do it?
Thanks. Dmitry.
Index: Zend/zend_execute.c
===
--- Zend/zend_execute.c (revision 305710)
+++ Zend/zend_execute.c (working copy)
@@ -1362,21 +1362,12 @@
}
}
-static inline zend_brk_cont_element* zend_brk_cont(zval *nest_levels_zval, int
array_offset, const zend_op_array *op_array, const temp_variable *Ts TSRMLS_DC)
+static inline zend_brk_cont_element* zend_brk_cont(int nest_levels, int
array_offset, const zend_op_array *op_array, const temp_variable *Ts TSRMLS_DC)
{
zval tmp;
- int nest_levels, original_nest_levels;
+ int original_nest_levels = nest_levels;
zend_brk_cont_element *jmp_to;
- if (nest_levels_zval-type != IS_LONG) {
- tmp = *nest_levels_zval;
- zval_copy_ctor(tmp);
- convert_to_long(tmp);
- nest_levels = tmp.value.lval;
- } else {
- nest_levels = nest_levels_zval-value.lval;
- }
- original_nest_levels = nest_levels;
do {
if (array_offset==-1) {
zend_error_noreturn(E_ERROR, Cannot break/continue %d
level%s, original_nest_levels, (original_nest_levels == 1) ? : s);
Index: Zend/zend_vm_execute.h
===
--- Zend/zend_vm_execute.h (revision 305710)
+++ Zend/zend_vm_execute.h (working copy)
@@ -1304,11 +1304,10 @@
static int ZEND_FASTCALL ZEND_BRK_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
-
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-op1.opline_num,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-op1.opline_num,
EX(op_array), EX_Ts() TSRMLS_CC);
ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
@@ -1317,11 +1316,10 @@
static int ZEND_FASTCALL
ZEND_CONT_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
-
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-op1.opline_num,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-op1.opline_num,
EX(op_array), EX_Ts() TSRMLS_CC);
ZEND_VM_JMP(EX(op_array)-opcodes + el-cont);
@@ -1334,7 +1332,7 @@
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-extended_value,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-extended_value,
EX(op_array), EX_Ts() TSRMLS_CC);
brk_opline = EX(op_array)-opcodes + el-brk;
@@ -1477,32 +1475,6 @@
}
-static int ZEND_FASTCALL ZEND_BRK_SPEC_TMP_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_tmp(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- zval_dtor(free_op2.var);
- ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
-}
-
-static int ZEND_FASTCALL ZEND_CONT_SPEC_TMP_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_tmp(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- zval_dtor(free_op2.var);
- ZEND_VM_JMP(EX(op_array)-opcodes + el-cont);
-}
-
static int ZEND_FASTCALL
ZEND_FETCH_CLASS_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
@@ -1599,32 +1571,6 @@
}
-static int ZEND_FASTCALL ZEND_BRK_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_var(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- if (free_op2.var) {zval_ptr_dtor(free_op2.var);};
- ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
-}
-
-static int ZEND_FASTCALL ZEND_CONT_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_var(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
Re: [PHP-DEV] break/continue $var
On Wed, 24 Nov 2010, Dmitry Stogov wrote: the proposed patch (backport from php6) is attached. I think this feature is completely useless and it was agreed to remove it about 5 years ago. Derick, can I commit the patch today? Sure. You know this stuff best :-) 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] Hold off 5.4
On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote:
On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
On 2010-11-23, Derick Rethans der...@php.net wrote:
On Mon, 22 Nov 2010, Felipe Pena wrote:
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class
named int or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
Perhaps we can reduce the current list of classes:
int, integer, real, double, string, binary, scalar, array, object,
bool, boolean
to what the manual uses though (for prototypes):
int, float, string, binary, scalar, array, object, bool
(Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
Sorry, but this is actually a pretty grave BC break.
Currently, you can do the following:
namespace Foo\Validator;
class Int {}
During our namespace discussion, this is exactly what I warned about. In
order to make use of namespaces, you need to have atleast two elements
in your class names otherwise we can still never introduce a new class.
But that was not listened too.
As Sebastian noted, it seems this should be addressed with the new
lexer; I'd argue that if the current type hinting must introduce new
keywords, it should wait until the new lexer is in place in order to
insulate end-users from such changes.
The new lexer however, is a slower; so not a viable solution right now.
With a defined release process, *everyone* knows what must be done, by
when, making the process more transparent and *gasp* democratic.
Well, I don't think we've ever been democratic. I probably think
that that wouldn't even work. Also, I think an alpha has pretty much
been announce nicely on time for people to know what's happening.
I think what Matthew suggest here is something in the line of democratically
defining a release process up front: features you would like to get in (a
roadmap that clearly states that the content can change up until a feature
freeze), a deadline for the feature freeze so that the process is
predictable and appoint a release manager to be in charge of the branch.
Something like:
- Branching next version from day one so you have one called next and one
called trunk for edge stuff, and appoint a release manager to approve
features as they are merged from development branch(es)
Alternatively (among several possible branch strategies) in DVCS you could
use topic branches for the edge implementations, this is cleaner (maybe),
but the point is to have a release branch that can be stabilized at anytime.
For a more in-depth branching possibility see:
http://nvie.com/posts/a-successful-git-branching-model/
- Define a feature freeze date, anything not ready feature or stability wise
is moved to Next Next roadmap (they are not in the Next release branch
anyway as it only has feature complete features at any point)
And branch off Next Next and appoint a release manager for that branch so
there is always an active release branch.
This will give a more predictable release schedule for everyone involved,
especially for php users as it will give them a real hint on when the
testing process of the next version will begin and some clue on when it
might get finalized. All without having to introduce full fledge scrum and /
or a strict release process.
- ar
Re: [PHP-DEV] Hold off 5.4
On Wed, Nov 24, 2010 at 1:41 PM, André Rømcke a...@ez.no wrote:
On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote:
On Tue, 23 Nov 2010, Matthew Weier O'Phinney wrote:
On 2010-11-23, Derick Rethans der...@php.net wrote:
On Mon, 22 Nov 2010, Felipe Pena wrote:
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class
named int or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
Perhaps we can reduce the current list of classes:
int, integer, real, double, string, binary, scalar, array, object,
bool, boolean
to what the manual uses though (for prototypes):
int, float, string, binary, scalar, array, object, bool
(Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php
)
Sorry, but this is actually a pretty grave BC break.
Currently, you can do the following:
namespace Foo\Validator;
class Int {}
During our namespace discussion, this is exactly what I warned about. In
order to make use of namespaces, you need to have atleast two elements
in your class names otherwise we can still never introduce a new class.
But that was not listened too.
As Sebastian noted, it seems this should be addressed with the new
lexer; I'd argue that if the current type hinting must introduce new
keywords, it should wait until the new lexer is in place in order to
insulate end-users from such changes.
The new lexer however, is a slower; so not a viable solution right now.
With a defined release process, *everyone* knows what must be done, by
when, making the process more transparent and *gasp* democratic.
Well, I don't think we've ever been democratic. I probably think
that that wouldn't even work. Also, I think an alpha has pretty much
been announce nicely on time for people to know what's happening.
I think what Matthew suggest here is something in the line of
democratically defining a release process up front: features you would like
to get in (a roadmap that clearly states that the content can change up
until a feature freeze), a deadline for the feature freeze so that the
process is predictable and appoint a release manager to be in charge of the
branch.
Something like:
- Branching next version from day one so you have one called next and one
called trunk for edge stuff, and appoint a release manager to approve
features as they are merged from development branch(es)
Alternatively (among several possible branch strategies) in DVCS you could
use topic branches for the edge implementations, this is cleaner (maybe),
but the point is to have a release branch that can be stabilized at anytime.
For a more in-depth branching possibility see:
http://nvie.com/posts/a-successful-git-branching-model/
- Define a feature freeze date, anything not ready feature or stability
wise is moved to Next Next roadmap (they are not in the Next release branch
anyway as it only has feature complete features at any point)
And branch off Next Next and appoint a release manager for that branch so
there is always an active release branch.
When feature freeze date for Next is reached.
This will give a more predictable release schedule for everyone involved,
especially for php users as it will give them a real hint on when the
testing process of the next version will begin and some clue on when it
might get finalized. All without having to introduce full fledge scrum and /
or a strict release process.
- ar
Re: [PHP-DEV] break/continue $var
Hi Dmitry,
From a BC point of view, the impact will be minimal. The only project
I found relying on this syntax is XPath class [1].
Please add a note the upgrade guide as well in trunk, maybe in a BC
break sections.
[1] http://google.com/codesearch?hl=ensa=Nq=lang:php+break\s{1,}%28\%24\w%29
Cheers,
On Wed, Nov 24, 2010 at 1:11 PM, Dmitry Stogov dmi...@zend.com wrote:
the proposed patch (backport from php6) is attached.
I think this feature is completely useless and it was agreed to remove it
about 5 years ago.
Derick, can I commit the patch today?
Thanks. Dmitry.
Dmitry Stogov wrote:
Hi,
Previously we decided to remove break/continue $var syntax.
I even implemented it in PHP6 brunch, however it wasn't backported into
trunk. Could I do it?
Thanks. Dmitry.
Index: Zend/zend_execute.c
===
--- Zend/zend_execute.c (revision 305710)
+++ Zend/zend_execute.c (working copy)
@@ -1362,21 +1362,12 @@
}
}
-static inline zend_brk_cont_element* zend_brk_cont(zval *nest_levels_zval,
int array_offset, const zend_op_array *op_array, const temp_variable *Ts
TSRMLS_DC)
+static inline zend_brk_cont_element* zend_brk_cont(int nest_levels, int
array_offset, const zend_op_array *op_array, const temp_variable *Ts
TSRMLS_DC)
{
zval tmp;
- int nest_levels, original_nest_levels;
+ int original_nest_levels = nest_levels;
zend_brk_cont_element *jmp_to;
- if (nest_levels_zval-type != IS_LONG) {
- tmp = *nest_levels_zval;
- zval_copy_ctor(tmp);
- convert_to_long(tmp);
- nest_levels = tmp.value.lval;
- } else {
- nest_levels = nest_levels_zval-value.lval;
- }
- original_nest_levels = nest_levels;
do {
if (array_offset==-1) {
zend_error_noreturn(E_ERROR, Cannot break/continue
%d level%s, original_nest_levels, (original_nest_levels == 1) ? : s);
Index: Zend/zend_vm_execute.h
===
--- Zend/zend_vm_execute.h (revision 305710)
+++ Zend/zend_vm_execute.h (working copy)
@@ -1304,11 +1304,10 @@
static int ZEND_FASTCALL
ZEND_BRK_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
-
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-op1.opline_num,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-op1.opline_num,
EX(op_array), EX_Ts() TSRMLS_CC);
ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
@@ -1317,11 +1316,10 @@
static int ZEND_FASTCALL
ZEND_CONT_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
-
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-op1.opline_num,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-op1.opline_num,
EX(op_array), EX_Ts() TSRMLS_CC);
ZEND_VM_JMP(EX(op_array)-opcodes + el-cont);
@@ -1334,7 +1332,7 @@
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-extended_value,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-extended_value,
EX(op_array), EX_Ts() TSRMLS_CC);
brk_opline = EX(op_array)-opcodes + el-brk;
@@ -1477,32 +1475,6 @@
}
-static int ZEND_FASTCALL
ZEND_BRK_SPEC_TMP_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_tmp(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- zval_dtor(free_op2.var);
- ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
-}
-
-static int ZEND_FASTCALL
ZEND_CONT_SPEC_TMP_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_tmp(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- zval_dtor(free_op2.var);
- ZEND_VM_JMP(EX(op_array)-opcodes + el-cont);
-}
-
static int ZEND_FASTCALL
ZEND_FETCH_CLASS_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
@@ -1599,32 +1571,6 @@
}
-static int ZEND_FASTCALL
ZEND_BRK_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_var(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- if
Re: [PHP-DEV] break/continue $var
Pierre Joye wrote:
Hi Dmitry,
From a BC point of view, the impact will be minimal. The only project
I found relying on this syntax is XPath class [1].
I'm wondered why they use it, because their var ($parseBlock) is always 1.
Please add a note the upgrade guide as well in trunk, maybe in a BC
break sections.
done.
Thanks. Dmitry.
[1] http://google.com/codesearch?hl=ensa=Nq=lang:php+break\s{1,}%28\%24\w%29
Cheers,
On Wed, Nov 24, 2010 at 1:11 PM, Dmitry Stogov dmi...@zend.com wrote:
the proposed patch (backport from php6) is attached.
I think this feature is completely useless and it was agreed to remove it
about 5 years ago.
Derick, can I commit the patch today?
Thanks. Dmitry.
Dmitry Stogov wrote:
Hi,
Previously we decided to remove break/continue $var syntax.
I even implemented it in PHP6 brunch, however it wasn't backported into
trunk. Could I do it?
Thanks. Dmitry.
Index: Zend/zend_execute.c
===
--- Zend/zend_execute.c (revision 305710)
+++ Zend/zend_execute.c (working copy)
@@ -1362,21 +1362,12 @@
}
}
-static inline zend_brk_cont_element* zend_brk_cont(zval *nest_levels_zval,
int array_offset, const zend_op_array *op_array, const temp_variable *Ts
TSRMLS_DC)
+static inline zend_brk_cont_element* zend_brk_cont(int nest_levels, int
array_offset, const zend_op_array *op_array, const temp_variable *Ts
TSRMLS_DC)
{
zval tmp;
- int nest_levels, original_nest_levels;
+ int original_nest_levels = nest_levels;
zend_brk_cont_element *jmp_to;
- if (nest_levels_zval-type != IS_LONG) {
- tmp = *nest_levels_zval;
- zval_copy_ctor(tmp);
- convert_to_long(tmp);
- nest_levels = tmp.value.lval;
- } else {
- nest_levels = nest_levels_zval-value.lval;
- }
- original_nest_levels = nest_levels;
do {
if (array_offset==-1) {
zend_error_noreturn(E_ERROR, Cannot break/continue
%d level%s, original_nest_levels, (original_nest_levels == 1) ? : s);
Index: Zend/zend_vm_execute.h
===
--- Zend/zend_vm_execute.h (revision 305710)
+++ Zend/zend_vm_execute.h (working copy)
@@ -1304,11 +1304,10 @@
static int ZEND_FASTCALL
ZEND_BRK_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
-
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-op1.opline_num,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-op1.opline_num,
EX(op_array), EX_Ts() TSRMLS_CC);
ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
@@ -1317,11 +1316,10 @@
static int ZEND_FASTCALL
ZEND_CONT_SPEC_CONST_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
-
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-op1.opline_num,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-op1.opline_num,
EX(op_array), EX_Ts() TSRMLS_CC);
ZEND_VM_JMP(EX(op_array)-opcodes + el-cont);
@@ -1334,7 +1332,7 @@
zend_brk_cont_element *el;
SAVE_OPLINE();
- el = zend_brk_cont(opline-op2.zv, opline-extended_value,
+ el = zend_brk_cont(Z_LVAL_P(opline-op2.zv), opline-extended_value,
EX(op_array), EX_Ts() TSRMLS_CC);
brk_opline = EX(op_array)-opcodes + el-brk;
@@ -1477,32 +1475,6 @@
}
-static int ZEND_FASTCALL
ZEND_BRK_SPEC_TMP_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_tmp(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- zval_dtor(free_op2.var);
- ZEND_VM_JMP(EX(op_array)-opcodes + el-brk);
-}
-
-static int ZEND_FASTCALL
ZEND_CONT_SPEC_TMP_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_tmp(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- zval_dtor(free_op2.var);
- ZEND_VM_JMP(EX(op_array)-opcodes + el-cont);
-}
-
static int ZEND_FASTCALL
ZEND_FETCH_CLASS_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
USE_OPLINE
@@ -1599,32 +1571,6 @@
}
-static int ZEND_FASTCALL
ZEND_BRK_SPEC_VAR_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
-{
- USE_OPLINE
- zend_free_op free_op2;
- zend_brk_cont_element *el;
-
- SAVE_OPLINE();
- el = zend_brk_cont(_get_zval_ptr_var(opline-op2.var, EX_Ts(),
free_op2 TSRMLS_CC), opline-op1.opline_num,
- EX(op_array), EX_Ts() TSRMLS_CC);
- if
[PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter
Hi,
I filed a bug report with an attached patch that adds an E_STRICT warning when
defining a function with a required parameter after an optional function
parameter, for example:
function foo($optional = 1, $required) {}
Although doing this works, code written like that is probably making a faulty
assumption somewhere, and emitting this error would help raise the quality of
php code.
The bug and patch are here: http://bugs.php.net/bug.php?id=53399
The patch applies against both the PHP 5.3 branch, and trunk. I'm not sure I'd
advocate including it in PHP 5.3, but I'd definitely like to see it in 5.4. The
patch also includes two tests, and fixes this problem in the
Zend/tests/call_user_func_005.phpt test, which is the only test I found that
fails as a result.
At some point in the future, I would like to make this a more severe error than
an E_STRICT, but I'd rather not immediately break code that (until now) worked
without warning.
Thoughts/comments?
-John
--
John Bafford
http://bafford.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter
On Nov 24 12:28:38, John Bafford wrote:
Hi,
I filed a bug report with an attached patch that adds an E_STRICT warning
when defining a function with a required parameter after an optional function
parameter, for example:
function foo($optional = 1, $required) {}
Although doing this works, code written like that is probably making a faulty
assumption somewhere, and emitting this error would help raise the quality of
php code.
The bug and patch are here: http://bugs.php.net/bug.php?id=53399
The patch applies against both the PHP 5.3 branch, and trunk. I'm not sure
I'd advocate including it in PHP 5.3, but I'd definitely like to see it in
5.4. The patch also includes two tests, and fixes this problem in the
Zend/tests/call_user_func_005.phpt test, which is the only test I found that
fails as a result.
At some point in the future, I would like to make this a more severe error
than an E_STRICT, but I'd rather not immediately break code that (until now)
worked without warning.
Thoughts/comments?
Given the semantics of PHP arguments, there is nothing wrong with
defining a required argument after an optional one, and in some cases
it is required. Consider:
function foo(Plop $a, $b) {}
if you want to allow 'null' for $a as well, you have to write:
function foo(Plop $a = null, $b) {}
Best,
-John
--
John Bafford
http://bafford.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Revise callback Psuedo-type to support new Closure class ?
Hi all,
I had a thought this morning and would like some feedback. Don't you think
it would make sense to allow the callback psuedo-type to also allow the new
Closure class to be an acceptable data type? A simple example that would be
nice to have working would be
?php
$fClosure = function($val, $key) {
echo $key = $val . PHP_EOL;
}
$aNumbers = array(5, 4, 3, 2, 1);
array_walk($aNumbers, $fClosure);
?
Thoughts ?
-nathan
[PHP-DEV] Re: Revise callback Psuedo-type to support new Closure class ?
Ummm... never mind!
Sorry for the noise!
-nathan
On Wed, Nov 24, 2010 at 11:00 AM, Nathan Nobbe quickshif...@gmail.comwrote:
Hi all,
I had a thought this morning and would like some feedback. Don't you think
it would make sense to allow the callback psuedo-type to also allow the new
Closure class to be an acceptable data type? A simple example that would be
nice to have working would be
?php
$fClosure = function($val, $key) {
echo $key = $val . PHP_EOL;
}
$aNumbers = array(5, 4, 3, 2, 1);
array_walk($aNumbers, $fClosure);
?
Thoughts ?
-nathan
Re: [PHP-DEV] Add E_STRICT when defining a required function parameter after an optional parameter
Hi! Given the semantics of PHP arguments, there is nothing wrong with defining a required argument after an optional one, and in some cases it is required. Consider: I think there's something wrong with it, primarily - the fact that it doesn't really make any sense. The object/null thing is a kludge. Unfortunately, I don't see a proper way to handle this without named arguments. -- 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] [RFC] Release Process
hi, 2010/11/23 Ilia Alshanetsky i...@prohost.org: I think support 5 or even 3 parallel versions will be highly impractical and extra-ordinarily challenging. I think we need a plan that limits us to 2 versions and perhaps a 3rd one for critical security fixes only. Yes, that's what the two examples tried to show. Also reducing the bugs fixing period (move earlier to security mode only) could help a lot. Having one release in bugs fixes mode and two in security only is not too much work. The one thing we have to improve to achieve this goal (be 2 or 3 active versions) is to share tests infrastructure. At our labs we are working on improving our tests platforms with more BC tests, performance/stress tests and apps testing using the usual apps (wp, joomla, drupal, etc.) with setup and usage. We would like to add frameworks too soonish, but for that we would prefer to work with the framework directly. Doing so will let us tests a RC withing a couple of days with a high level of confidence. I also think that with a bug fixes and security only mode will reduce a release period to a month (2 RCs) for 99% of the releases. Feel free to ping me if you are one of the QA lead/lead of a framework or app and have a tests suite ready to be used. 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] Release Process
hi, amen. On Tue, Nov 23, 2010 at 3:17 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2010-11-23, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- if I want to get this in time for the release, what solution will work best? I used to love the ad hoc nature of we'll release when it's ready. However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. Release is in 3 months? Okay, let's get rolling on this! * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. I can't do it by this release, but I should have no trouble making the next. * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- 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] Hold off 5.4
hi Derick, On Tue, Nov 23, 2010 at 10:57 AM, Derick Rethans der...@php.net wrote: I am absolutely against stalling again! I am absolutely against going into a release process with the current state of the affairs. I think it would be much better for everyone if we first agree on the release process RFC, including the selection of the release managers, the features inclusions and the BC breaks policy. Last but not least, I don't think the type hinting (or strict typing) got any agreement or go any approved RFC. That alone is a no-go for a release. 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] Hold off 5.4
hi, hi, On Tue, Nov 23, 2010 at 3:56 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Zeev Suraski wrote: To me this alpha would be a this is what we're mostly likely going to have thing. I wouldn't like to see new major features, engine rework being done; but I also think we shouldn't try to remove stuff from it unless really necessary. If that's the case, count me in those who oppose the release of the current codebase as an alpha. I find it interesting that apparently so many people don't want a new PHP version out, but forget to say what they think needs fixing. Instead of opposing, can we not do just some work? I do want a new PHP release. I do want a clear, transparent, honest process to decide which features get in, to select the release managers and to get the release out. It also happens that I do some work as well. 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] Hold off 5.4
hi, On Tue, Nov 23, 2010 at 3:53 PM, Derick Rethans der...@php.net wrote: Well, I don't think we've ever been democratic. Neither have we been dictatorial. Announcing a new major (x.y+1.z) release in the middle of some of the largest conferences (knowing that many core devs won't follow the list) and for a couple of weeks later was not the best thing to do. To commit something that did not get any consensus and then force us to go out with a release is bad. -- 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: Hold off 5.4
On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner m...@php.net wrote: On 11/23/2010 02:30 AM, Felipe Pena wrote: 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. +1 +1 here too. -- 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] hinting proposals status
hi, To avoid any possible issue or features introduced without consensus, I'd to ask to first revert the current implementation from trunk. There is clearly no consensus on this feature and the RFCs are either incomplete or without actual implementations (http://wiki.php.net/rfc/typechecking). Then every developer involved in one of these proposals is free to create a branch to implement or improve them. I would suggest to use 5.3 as base as it will be show clearly any kind of BC that could be introduced. Once a proposal is considered as ready for testing and voting, then we can actually test its branch and take an informed decision. I will also proudly provide snapshots or builds for any branch at wish, via the http://rmtools.php.net tools, like the onesones available here (windows builds bot only for now, more coming): http://rmtools.php.net/snaps/ By the way, this way of doing things is described in the release process RFC, it is called a feature preview release. 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
[PHP-DEV] git anyone?
hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. 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] Add E_STRICT when defining a required function parameter after an optional parameter
On Nov 24, 2010, at 14:02, Stas Malyshev wrote: Given the semantics of PHP arguments, there is nothing wrong with defining a required argument after an optional one, and in some cases it is required. Consider: I think there's something wrong with it, primarily - the fact that it doesn't really make any sense. The object/null thing is a kludge. Unfortunately, I don't see a proper way to handle this without named arguments. Ok, I re-wrote the patch and test: http://bugs.php.net/patch-display.php?bug_id=53399patch=strict-required-opt2.patchrevision=latest Now, the test happens in zend_do_end_function_declaration(). It loops through each of the function's parameters and emits the E_STRICT if it detects a required parameter after an optional parameter. The tests are loosened so that Class $param = null will not by itself trigger the warning. So it's not a 100% solution since we have to allow for the object/null kludge, but it's still an improvement from not having anything at all. To make this work, I added a field to zend_arg_info, 'optional', which is populated in zend_do_receive_arg(). Also, we might want to modify php_reflection.c:_parameter_string() to use zend_arg_info.optional, which would allow indicating whether the parameter was declared optional vs. whether it actually is being treated as optional. I think I can move the implementation back into zend_do_receive_arg(), but before I go ahead and do that, I'd like to make sure everyone's happier with this solution than my first. It might also be possible to get rid of zend_arg_info.optional, but I'd need to know how/if it's possible to access the relevant oplines for the rest of the function's parameters. -John -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Wed, Nov 24, 2010 at 20:47, Pierre Joye pierre@gmail.com wrote: hi, [snip] Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. You might recall several conversations on this during the period where Gwynne was migrating us from CVS to SVN in 2008/09. Two two threads that stand out most in my mind were Rasmus' thoughts on the matter[1] and David Soria Parra actually working toward using git --- or at least git-svn[2]. There were several other threads on the subject as well, so unless opinions have changed, you may already have some folks in your corner. ^1: http://news.php.net/svn.migration/255 ^2: http://news.php.net/php.internals/44942 -- /Daniel P. Brown -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 25 November 2010 09:47, Pierre Joye pierre@gmail.com wrote: Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I would be +1 on this, where 1 is the biggest 1 possible without it becoming 2. :) git-svn is a reasonable alternative for smaller repositories and projects (I use it at work on a daily basis to deal with older projects that we haven't migrated to git), but the PHP repository is difficult to use effectively with it, since it (in my experience, at least) requires a checkout of every revision for proper handling of branches and tags. git-svn also imposes some restrictions on developer workflow which aren't insurmountable, but do limit what you can do relative to a real git repository. So, in short, I'd love to see us move to git. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Wednesday, November 24, 2010 8:12:25 pm Daniel Brown wrote: On Wed, Nov 24, 2010 at 20:47, Pierre Joye pierre@gmail.com wrote: hi, [snip] Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. You might recall several conversations on this during the period where Gwynne was migrating us from CVS to SVN in 2008/09. Two two threads that stand out most in my mind were Rasmus' thoughts on the matter[1] and David Soria Parra actually working toward using git --- or at least git-svn[2]. There were several other threads on the subject as well, so unless opinions have changed, you may already have some folks in your corner. ^1: http://news.php.net/svn.migration/255 ^2: http://news.php.net/php.internals/44942 FWIW, the KDE project migrated from CVS to SVN a few years ago and is now in the process of migrating to Git following numerous KDE projects moving to Github of their own accord. They're doing a piece-meal approach with projects migrating bit by bit. I believe they are hosting their own Git setup but I'm not certain of that. The Drupal project skipped SVN entirely and is currently in the process of migrating our entire infrastructure from CVS to Git, which we will be self- hosting. Numerous Drupal projects were already migrating to Github and we decided, basically, CVS sucks and people are voting with their feet for Git. We opted to setup our own Git infrastructure rather than use GitHub's because our development toolchain is very tightly coupled with our version control system and issue queue history, and we wanted to retain that. We couldn't do that on Github, but building our own we could. A nice side-effect of this process (in progress as we speak) is a number of more generic tools (many Drupal-based, I grant) for version control handling, particularly Git. By the time we're done (hopefully late Q1 2011) we should have a number of people who know a disturbing amount about Git and Git-PHP, and I suspect many could be coaxed to at least provide advise and consultation if not actual labor. (I am not one of those people so I can't speak for them, but I would certainly be willing to poke and prod people into offering what help they can. g) Having been an SVN fan for a long time, I must say I am *really* liking working with Git for the past year or so on various projects. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. The main reasons we moved to SVN and not Git include: - Less of a learning curve, because SVN is like CVS - Most of the CVS-SVN work was already finished - A few old timers didn't want us using Git - We aren't sure how the authentication/karma system would work Most people wanted (and still want) to move to Git, but moving to SVN was a simpler process. Any proposal towards Git should include how it'd work. Also, Github (yes or no) is another part of this. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
Hi! With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Really? I think you're blowing this all way out of proportion. I don't mind a yearly release cycle, as we should get out more releases. I don't mind a monthly release cycle for .z releases. I think the idea is not focusing on yearly or monthly but having some predictable schedule. Nobody says it should be set in stone, let's be realistic here - if we need to slip a release here and there, we'd do it. But having known targets is the goal, not having releases whenever somebody on the list wakes up and decides to have a release. I think the project needs to grow up a bit and have at least some semblance of release schedule. The mere existence of it written somewhere public would motivate people to adhere to it. -- 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] git anyone?
Hi! We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. My personal experience is that git runs circles around svn when it comes to merging and branching, etc. There's some learning curve but you can get used to it in less than a month. However, there are a lot of practical challenges (auth, etc.) that need to be solved. I personally wouldn't mind using git but we need to find a brave soul that would agree to figure out all the challenges. As for now, we already have github mirror, so maybe private needs can be served by it... -- 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] [RFC] Release Process
-Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Wednesday, November 24, 2010 9:39 PM To: Derick Rethans Cc: Felipe Pena; internals Subject: Re: [PHP-DEV] [RFC] Release Process Hi! With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Really? I think you're blowing this all way out of proportion. I don't mind a yearly release cycle, as we should get out more releases. I don't mind a monthly release cycle for .z releases. I think the idea is not focusing on yearly or monthly but having some predictable schedule. Nobody says it should be set in stone, let's be realistic here - if we need to slip a release here and there, we'd do it. But having known targets is the goal, not having releases whenever somebody on the list wakes up and decides to have a release. I think the project needs to grow up a bit and have at least some semblance of release schedule. The mere existence of it written somewhere public would motivate people to adhere to it. I agree with that. More structure and predictability will be very valuable to the project. We created a lot of structure in Zend Framework and it has really paid off. Btw, we don't have to look far. Just the change in having people document their suggestions via RFCs already had a substantial impact on this project both in terms of peer review and having a long lasting trail of what made it into a given release. More structure will typically yield in higher quality, more visibility and therefore more motivation for people to contribute, and I believe also in more deliverables rather than less as people will work towards clear goals + be accepting if they miss them and they need to wait for the next release train. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] git anyone?
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Wednesday, November 24, 2010 5:47 PM To: PHP internals Subject: [PHP-DEV] git anyone? hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. I personally doubt moving will have a material positive impact on the project. I wouldn't particularly mind if all the issues were addressed but I wouldn't hold my breath that it will be game changing. It may be better to invest the effort elsewhere. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Pierre Joye wrote: Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Have you used git on Windows Pierre ... It is a joke! Yes one can get it to work, but only if you do not use anything that the git cygwin install destroys! And as yet there is no consensus on getting it working cross platform in things like Eclipse. At least hg works out of the box on both linux and windows, but like git THAT does not properly support sub-repo's and makes managing nice modularly constructed projects like PHP almost impossible. Trying to work with projects that write modular PHP code in either git or hg is simply not currently practical ... especially when half of your user base is still tied to windows! -- 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] git anyone?
On Thu, Nov 25, 2010 at 8:06 AM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Have you used git on Windows Pierre ... It is a joke! I'm pretty sure, that Pierre uses windows on his desktop. :) Tyrael
Re: [PHP-DEV] git anyone?
2010/11/25 Lester Caine les...@lsces.co.uk: Have you used git on Windows Pierre ... It is a joke! Yes one can get it to work, but only if you do not use anything that the git cygwin install destroys! And as yet there is no consensus on getting it working cross platform in things like Eclipse. At least hg works out of the box on both linux and windows, but like git THAT does not properly support sub-repo's and makes managing nice modularly constructed projects like PHP almost impossible. Trying to work with projects that write modular PHP code in either git or hg is simply not currently practical ... especially when half of your user base is still tied to windows! Git on Windows problems belong to the past since a while now: * mSysGit * TortoiseGit -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner m...@php.net wrote: On 11/23/2010 02:30 AM, Felipe Pena wrote: 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. The reality is that trunk is not going to be 5.4; it cannot be in its current state. The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing. The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This is an unreliable, laborious, crappy method for creating stable branches, and managing the repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and re-integrating is also a pretty crappy solution. So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work. Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now. We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories to more easily pull those changes into the appropriate branches. - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
2010/11/25 Pierre Joye pierre@gmail.com: hi, We have moved not too long ago and for what I see it gave some opportunities to many of us to see what are the other tools on the market, git and github in particular. I think 99% of the active developers here are on github or use git in one way or another. I think git could be a great help, maintaining multiple branches will be easier. It will also be very useful to develop new complex features requiring a longer development period. SVN works fine but merging is very limited and buggy, maintaining a branch while syncing changes from trunk/other branches is a very frustrating experiences. Please not I'm not requesting to do it now and here, only trying to get a feeling/poll about git usage. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org Definetely a big +1. But you don't want us to be geeky early adopters, do you? Let's wait everybody else did the svn-git migration before us like we always did :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
Patrick ALLAERT wrote: 2010/11/25 Lester Caineles...@lsces.co.uk: Have you used git on Windows Pierre ... It is a joke! Yes one can get it to work, but only if you do not use anything that the git cygwin install destroys! And as yet there is no consensus on getting it working cross platform in things like Eclipse. At least hg works out of the box on both linux and windows, but like git THAT does not properly support sub-repo's and makes managing nice modularly constructed projects like PHP almost impossible. Trying to work with projects that write modular PHP code in either git or hg is simply not currently practical ... especially when half of your user base is still tied to windows! Git on Windows problems belong to the past since a while now: * mSysGit Provide you don't use cygwin ALREADY on your machine !!! Install mSysGit and existing packages stop working ... * TortoiseGit TortoiseHg does it RIGHT and works on both Linux and Windows. TortoiseGit does not work on Linux ... Personally I run hg since I need cross platform capability for my customers, and hggit quite happily links to github but all of this has to be managed outside Eclipse since none of those tools work reliably. And we STILL have the problem of handling modular projects since neither do 'sub-repo' reliably. This area seems to be in a similar state of chaos to PHP with different factions all pushing their own agendas. Both git and hg are targeting compiled applications and ignore handing scripted applications like php, python, ruby and the like. 'You fix the problems when you build a project' simply does not work when you do not have anything to build! So while it may work for building PHP as a single program, a packaged distribution is a different matter. -- 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] Re: Hold off 5.4
2010/11/25 Davey Shafik da...@php.net: On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote: On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner m...@php.net wrote: On 11/23/2010 02:30 AM, Felipe Pena wrote: 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. The reality is that trunk is not going to be 5.4; it cannot be in its current state. The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing. The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks. This is an unreliable, laborious, crappy method for creating stable branches, and managing the repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and re-integrating is also a pretty crappy solution. So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work. Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now. We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits. This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks). Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable (hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories to more easily pull those changes into the appropriate branches. - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I think Davey has a clear view and a good explanation about the current situation. Trunk has been used for both short and long term development hence the difficulties to agree that trunk is about 5.4 or +. In a first place, we should decide on what to have for 5.4 and what to leave for the future. A technical way to do it would be to use git-svn locally, starting from the PHP_5_3 branch and merging it with trunk. git rebase -i can then be used easily to remove all the commits we don't want to appear in 5.4. -- Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
