hi,
Reviewing the votes and the arguments for the votes (negative or
positive), it seems that there is a little confusion or I miss the
reasoning behind the votes about the options.
The option #1 (Keep the old macro names for LONG vs. INT, STRLEN vs.
STRSIZE, etc.) and #2 (Keep zpp specs l, L, s, p as aliases to i, I,
S, P), which both drastically reduce code changes or #fidef usage, are
valid for 5.6 integration.
In the case this RFC is rejected for 5.6, these options are really not
what is planed to do for 6.x as we should do it the clean way, as
explained in the various discussions here and as many of the
opposition used as argument as well.
For those having voted no for 5.6 and the options, would you mind
explaining what are your wishes? It will help to move forward, no
matter the outcome of the votes.
Thanks!
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
The option #1 (Keep the old macro names for LONG vs. INT, STRLEN vs.
STRSIZE, etc.) and #2 (Keep zpp specs l, L, s, p as aliases to i, I,
S, P), which both drastically reduce code changes or #fidef usage, are
valid for 5.6 integration.
The first one seems to me relatively tame, at least unless I'm missing
something. I'm not one to give too much importance to precision of
naming of macros, but why not make it easy on people?
The second one, however, seems dangerous - that means if I forget to
convert some function that uses zpp, I get no indication at all, except
for random hard-to-debug crashes when it's used with wrong int type.
The alternative for this is (PHP_NEED_STRSIZE_COMPAT ? "Os|al" :
"OS|ai"), which feels my heart with dread and one of the reasons why I
lean to voting "no", even though I like the idea of the cleanup. But
compared to the alternative, this is a better option. Because at least
this would fail fast in the case of trouble and will be discovered if
you have any half-decent tests on your extension. The other way means if
you forget to convert the zpp call and do convert the values involved,
you'd have very interesting debugging session waiting for you.
For those having voted no for 5.6 and the options, would you mind
explaining what are your wishes? It will help to move forward, no
matter the outcome of the votes.
My personal preference for now is to make this change base for PHP 6
branch. We've started talking on 6 anyway, and I don't see it out of the
possible to kick off real feature mapping and even start working on it
this year, and have at least early alphas sometime next year. This would
be our opportunity to break APIs to make them better. If that is not
what happening, what I am afraid of is that people - at least ones that
use custom extensions and work on sizeable products with non-trivial QA
cycles - would treat 5.6 as somewhat a theoretical exercise and would
wait it out for 6 (unless we starve them out by never delivering on it
in next 3-4 years). And that's not a good place for a release to be in.
I like the things done in 5.6, and I like the work Anatol and others
have done on 64-bit cleanup. But I'm afraid that by combining them we'd
harm them both.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
The option #1 (Keep the old macro names for LONG vs. INT, STRLEN vs.
STRSIZE, etc.) and #2 (Keep zpp specs l, L, s, p as aliases to i, I,
S, P), which both drastically reduce code changes or #fidef usage, are
valid for 5.6 integration.The first one seems to me relatively tame, at least unless I'm missing
something. I'm not one to give too much importance to precision of
naming of macros, but why not make it easy on people?The second one, however, seems dangerous - that means if I forget to
convert some function that uses zpp, I get no indication at all, except
for random hard-to-debug crashes when it's used with wrong int type.
The alternative for this is (PHP_NEED_STRSIZE_COMPAT ? "Os|al" :
"OS|ai"), which feels my heart with dread and one of the reasons why I
lean to voting "no", even though I like the idea of the cleanup. But
compared to the alternative, this is a better option. Because at least
this would fail fast in the case of trouble and will be discovered if
you have any half-decent tests on your extension. The other way means if
you forget to convert the zpp call and do convert the values involved,
you'd have very interesting debugging session waiting for you.For those having voted no for 5.6 and the options, would you mind
explaining what are your wishes? It will help to move forward, no
matter the outcome of the votes.My personal preference for now is to make this change base for PHP 6
branch. We've started talking on 6 anyway, and I don't see it out of the
possible to kick off real feature mapping and even start working on it
this year, and have at least early alphas sometime next year. This would
be our opportunity to break APIs to make them better. If that is not
what happening, what I am afraid of is that people - at least ones that
use custom extensions and work on sizeable products with non-trivial QA
cycles - would treat 5.6 as somewhat a theoretical exercise and would
wait it out for 6 (unless we starve them out by never delivering on it
in next 3-4 years). And that's not a good place for a release to be in.
I like the things done in 5.6, and I like the work Anatol and others
have done on 64-bit cleanup. But I'm afraid that by combining them we'd
harm them both.
My personal preference for now is to make this change base for PHP 6
branch.
+1000 ... this is the only option that really makes sense ...
Cheers
Joe
Pierre Joye wrote:
In the case this RFC is rejected for 5.6, these options are really not
what is planed to do for 6.x as we should do it the clean way, as
explained in the various discussions here and as many of the
opposition used as argument as well.
See next ...
For those having voted no for 5.6 and the options, would you mind
explaining what are your wishes? It will help to move forward, no
matter the outcome of the votes.
Are you really saying that this is just a hack to get 5.6 working and that it
will all require re-working in PHP6?
I'm not particularly bothered what you do with 5.6 myself and I'm sure a lot
more 'users' are probably in the same boat. It will still be a few years before
I've managed to get everything up to PHP5.4 and by then hopefully we will have
PHP6 with a nice clean Unicode base ( which in itself I think requires dropping
case insensitivity ) and a nice clean 32/64 bit operational switch. Yes there
will still be a large number of 32bit only machines around so PHP6 will have to
work transparently with them!
Basically I can't see any point wasting time on PHP5.6 at all. Except as a
springboard to 'for 6.x as we should do it the clean way'! The usage figures
show just how important the current builds are and I'm not seeing any reason to
bother with 5.5 currently either ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
In the case this RFC is rejected for 5.6, these options are really not
what is planed to do for 6.x as we should do it the clean way, as
explained in the various discussions here and as many of the
opposition used as argument as well.For those having voted no for 5.6 and the options, would you mind
explaining what are your wishes? It will help to move forward, no
matter the outcome of the votes.
I thought that was obvious. I prefer not to see this change in 5.x at
all, but in case it passes the vote I would want to minimize the API
damage. Hence the "No" vote and the hedge votes for minimal 5.x API
breakage. This has nothing to do with PHP 6. For PHP 6 there will be
other API changes which may very well affect this.
-Rasmus