Re: [PHP-DEV] [PATCH] Fix for bug #55754
hi, 2011/10/6 Johannes Schlüter johan...@schlueters.de: I think 5.3 is fine, too. But please extend the test a bit. The current one will pass even if the process segfaults. At least print something at the end. I think it is not safe for 5.3. While the patch looks trivial or harmless, it is in an area where the consequences of a new bug, even for an edge case, can be very bad. The ratio risk/benefit is high, especially when it is only about fixing a strict warning. I would rather wait (maybe 5.4 last RC or final) before applying it to 5.3. We don't need a 5.3.7/8 again :) 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] Time zone database shut down by legal threat
hi, On Fri, Oct 7, 2011 at 5:06 AM, John Crenshaw johncrens...@priacta.com wrote: From: J. Adams [mailto:zardozro...@gmail.com] Sent: Thursday, October 06, 2011 7:46 PM Subject: Re: [PHP-DEV] Time zone database shut down by legal threat Perhaps we could all contact Astrolabe and voice our complaints? http://alabe.com/ Wow, someone from PR should have really sent a memo that martyring an open source hero is a terrible idea. Their email address is astrol...@alabe.com. I've sent mine. Let the angry flood begin. Also, if anyone cares, you can read the full complaint at http://www.scribd.com/doc/67760407/ASTROLABE-INC-Vs-ARTHUR-DAVID-OLSON-and-PAUL-EGGERT-Complaint. While it sounds funny to do, please do not use this mailing list to call for a bomb mail action. 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] Time zone database shut down by legal threat
David Zülke wrote: FYI:http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. I suppose the next question has to be one of what source was used by 'The American Atlas' to put the information in that document? Presumably the proceedings of the US government? As an aside, is there anything to prevent a copy of the database which simply removes the identified historic data until the American lawyers have milked it for all it's worth? The key phrase from the database is obviously '# It is the source for most of the pre-1991 US entries below.' I have been unable to find anything on Eggert's links page that references the ACS Atlas in the manor claimed? It is just a links page to everybody elses data? So shouldn't the complaint actually IDENTIFY the data they are claiming is copied? What historic data international data is included in the ACS Atlas? Of cause it would be nice if Olson had an historic email from ACS Publishing ;) -- 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] Time zone database shut down by legal threat
Lester Caine wrote: David Zülke wrote: FYI:http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. I suppose the next question has to be one of what source was used by 'The American Atlas' to put the information in that document? Presumably the proceedings of the US government? As an aside, is there anything to prevent a copy of the database which simply removes the identified historic data until the American lawyers have milked it for all it's worth? The key phrase from the database is obviously '# It is the source for most of the pre-1991 US entries below.' I have been unable to find anything on Eggert's links page that references the ACS Atlas in the manor claimed? It is just a links page to everybody elses data? So shouldn't the complaint actually IDENTIFY the data they are claiming is copied? What historic data international data is included in the ACS Atlas? Of cause it would be nice if Olson had an historic email from ACS Publishing ;) A very informative link that poped up http://www.astrology-x-files.com/terranatlas.html That would seem to be another 'derived work' but the historic notes make interesting reading. -- 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] RM decision on BUG #55801 / FR #36424
Hi Stas, On Thu, 06 Oct 2011 17:26:49 +0200, Stas Malyshev wrote: Could you give a quick summary of what the decision point is just so I won't miss anything scanning through the discussion and these bugs? In r299770 [1] I introduced a global var_hash to serialize() so that recursive calls to serialize()/unserialize() can know about the same objects/variable references. This was IMO a good thing to do (tm), but it obviously broke serializ behaviour when called in __sleep/__wakeup, because of the order of calls: serialize(obj) - obj-__sleep does serialize() (in user code) - then internally serialize(obj-prop) happens unserialize(obj) - internally unserialize(obj-prop) is done - obj-__wakeup is called which does unserialize() (user code) As one can see the IDs of the referenced objects when unserializing cannot match the IDs at serialization time, because of the mixed up call order. So I can only see two solutions: - either disallow serialize/unserialize in __sleep/__wakeup - or revert r299770 ... unless someone else has a better idea. [1] http://svn.php.net/viewvc/?view=revisionrevision=299770 Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug #55754
Hi! On 10/6/11 5:59 PM, Daniel K. wrote: But what about 5.3? there is no ABI issue with this, just a spurious warning that goes away. Yeah, I agree with Pierre - it's not a huge problem, and the risk is there, so I'd hold it for 5.3 as it is the stable version. When 5.4 gets tested enough that we're confident this fix is 100% fine, we may backport then maybe. -- 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-DEV] Re: Time zone database shut down by legal threat
On Fri, 7 Oct 2011, David Zülke wrote: FYI: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. We don't actually bundle the database as rules. Instead, we bundle a compiled version of that, and the original rules do not remain in what we bundle. Not sure whether that means it impacts us or not, and I will not be making any comments about that. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Time zone database shut down by legal threat
Derick Rethans wrote: FYI:http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. We don't actually bundle the database as rules. Instead, we bundle a compiled version of that, and the original rules do not remain in what we bundle. Not sure whether that means it impacts us or not, and I will not be making any comments about that. Unfortunately if the courts rule that the data is not public domain, then any use of it would be blocked and liable to license claims? It is the current block on making any future updates to the data which is a problem that will need to be addressed at some point? So ignoring the problem is not really practical :( -- 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: Time zone database shut down by legal threat
hi Lester, See the blog post itself for more information. They create a mailing list to create an alternative database but not to argue about the legal case. I would suggest to discuss things there instead. Cheers, On Fri, Oct 7, 2011 at 1:18 PM, Lester Caine les...@lsces.co.uk wrote: Derick Rethans wrote: FYI:http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. We don't actually bundle the database as rules. Instead, we bundle a compiled version of that, and the original rules do not remain in what we bundle. Not sure whether that means it impacts us or not, and I will not be making any comments about that. Unfortunately if the courts rule that the data is not public domain, then any use of it would be blocked and liable to license claims? It is the current block on making any future updates to the data which is a problem that will need to be addressed at some point? So ignoring the problem is not really practical :( -- 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 -- 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: Time zone database shut down by legal threat
Pierre Joye wrote: See the blog post itself for more information. They create a mailing list to create an alternative database but not to argue about the legal case. I would suggest to discuss things there instead. I had no doubt that the data would continue to exist, and it has been confirmed that it will be updated on the Australian site. The remaining question is Is there any problem using that data to update the PHP version? Since there are apparently already a number of corrections in the pipeline ... ;) -- 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: Time zone database shut down by legal threat
On Fri, 7 Oct 2011, Lester Caine wrote: Derick Rethans wrote: FYI:http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. We don't actually bundle the database as rules. Instead, we bundle a compiled version of that, and the original rules do not remain in what we bundle. Not sure whether that means it impacts us or not, and I will not be making any comments about that. Unfortunately if the courts rule that the data is not public domain, then any use of it would be blocked and liable to license claims? It is the current block on making any future updates to the data which is a problem that will need to be addressed at some point? So ignoring the problem is not really practical :( The TZ database maintenance is/was in the process of being put under the IANA as DAO is going on retirement soon. In that light, a new ML has already been set-up where the timezone database is now being maintained. New versions of the database will come out as usual, and we'll update PHP with those new database rules. 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] Time zone database shut down by legal threat
On Oct 6, 2011, at 3:24 PM, David Zülke wrote: FYI: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. David P.S. I hope Google/IBM/Oracle/whoever just buys those guys and then fires everyone. I spent this past week correlating PHP release dates and version numbers with celestial alignments, and can now guarantee that this lawsuit will implode immediately before the upcoming Uranus at Opposition event. Therefore, we are safe. Regards, A fellow Olson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Time zone database shut down by legal threat
Is the IANA tz database subject to the same constraints as the old one? If so, it may be subject to the same legal constraints. I believe it would be wise to seek some quality legal advice on the issue. I have tried to contact the Free Software Foundation and the EFF just to see what they might say. I'll pass on anything interesting. On 10/7/2011 6:55 AM, Derick Rethans wrote: On Fri, 7 Oct 2011, Lester Caine wrote: Derick Rethans wrote: FYI:http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. We don't actually bundle the database as rules. Instead, we bundle a compiled version of that, and the original rules do not remain in what we bundle. Not sure whether that means it impacts us or not, and I will not be making any comments about that. Unfortunately if the courts rule that the data is not public domain, then any use of it would be blocked and liable to license claims? It is the current block on making any future updates to the data which is a problem that will need to be addressed at some point? So ignoring the problem is not really practical :( The TZ database maintenance is/was in the process of being put under the IANA as DAO is going on retirement soon. In that light, a new ML has already been set-up where the timezone database is now being maintained. New versions of the database will come out as usual, and we'll update PHP with those new database rules. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
On Wed, Sep 7, 2011 at 8:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/28/11 10:55 PM, Gustavo Lopes wrote: I should ask someone with Zend karma to commit the closure rebinding patch. Context: https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope Vote: https://wiki.php.net/todo/php54/vote Done. -- 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 Hi. do we have a wiki/documentation about what exactly ended up in 5.4 from the Closure improvements? (Rebind) https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope is really hard to read, as it contains all of the suggested ideas and possible solutions, etc. if not, maybe someone with the required knowledge could start working on adding the documentation? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
On Fri, Oct 7, 2011 at 19:31, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Sep 7, 2011 at 8:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/28/11 10:55 PM, Gustavo Lopes wrote: I should ask someone with Zend karma to commit the closure rebinding patch. Context: https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope Vote: https://wiki.php.net/todo/php54/vote Done. -- 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 Hi. do we have a wiki/documentation about what exactly ended up in 5.4 from the Closure improvements? (Rebind) https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope is really hard to read, as it contains all of the suggested ideas and possible solutions, etc. if not, maybe someone with the required knowledge could start working on adding the documentation? The UPGRADING file is also completely worthless. I have no idea what is going on, as a dev, nor as a documentor. Be it traits, closures, or whatever random new parameter or function was added. When 5.3 came around, I literally had to diff the sources to figure out what was going on, I am not going through that again. The RM should have a 110% clear oversight over what has changed, new and removed, and should therefore write clear notes about it before an beta exists, then the doc team can take those notes and write proper docs. If that doesn't happen, we wind up with more features like streams and filters which took 5+ years to document. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] new foo()-bar()
On Tue, Nov 30, 2010 at 9:57 AM, Michael Wallner m...@php.net wrote: On 11/26/2010 08:36 PM, Felipe Pena wrote: Hi all, ... Other examples which describes the feature at http://wiki.php.net/rfc/instance-method-call Thoughts? +1 Finally. it seems that it didn't made it to the trunk/5.4. is there anything holding things back? I think Dmitry mentioned checking for memleaks and such, but I didn't remember seeing anybody really against the idea. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug #55754
On 10/07/2011 10:04 AM, Pierre Joye wrote:
especially when it is only about fixing a strict warning.
It's not _just_ about silencing a strict warning. It's about preventing
non-obvious fuck-ups in extensions as well, as I alluded to earlier in
the thread.
Consider an extension implementing a function like:
ZEND_BEGIN_ARG_INFO(arginfo_test, ZEND_SEND_PREFER_REF)
ZEND_END_ARG_INFO()
zend_function_entry test_functions[] = {
ZEND_FE(test, arginfo_test)
{NULL, NULL, NULL}
};
ZEND_FUNCTION(test)
{
zval ***argv;
int i, is_ref;
int argc = ZEND_NUM_ARGS();
argv = malloc(sizeof(zval **) * argc);
zend_get_parameters_array_ex(argc, argv);
for (i = 0; i argc; i++) {
is_ref = PZVAL_IS_REF(*(argv[i]));
if (is_ref) {
/* Let's update it, and possibly
be in for a nice surprise */
if (Z_TYPE_PP(argv[i]) == IS_LONG)
Z_LVAL_PP(argv[i])++;
if (Z_TYPE_PP(argv[i]) == IS_STRING)
ZVAL_STRING(*argv[i], surprise, 1);
}
zend_error(E_USER_NOTICE,
Param %d was%s received by ref,
i, is_ref ? : not);
}
free(argv);
RETURN_TRUE;
}
Then doing...
php -d extension=test.so -r '$a = 1; $b = 2; $str1 = foo; \
test($str1, $str2 = bar, $a, $b = 3, NULL, str); \
echo a: $a, b: $b, str1: $str1, str2: $str2\n;'
...would currently result in:
===
Notice: Param 0 was received by ref in Command line code on line 1
Notice: Param 1 was received by ref in Command line code on line 1
Notice: Param 2 was received by ref in Command line code on line 1
Notice: Param 3 was received by ref in Command line code on line 1
a: 2, b: 4, str1: surprise, str2: surprise
===
Which I think is a bit surprising in the case of 'b' and 'str2', whereas
after my patch it would be:
===
Notice: Param 0 was received by ref in Command line code on line 1
Notice: Param 1 was not received by ref in Command line code on line 1
Notice: Param 2 was received by ref in Command line code on line 1
Notice: Param 3 was not received by ref in Command line code on line 1
a: 2, b: 3, str1: surprise, str2: bar
===
Which I think is not as surprising.
I would
rather wait (maybe 5.4 last RC or final) before applying it to 5.3. We
don't need a 5.3.7/8 again :)
Sure, it does not seem like people have been tripping over this left and
right, and given the change in behaviour, it may not be worth the risk.
That said, I'd be _very_ surprised, and a bit sad if anyone is relying
on the current buggy behaviour.
Daniel K.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
On Fri, 07 Oct 2011 18:31:42 +0100, Ferenc Kovacs tyr...@gmail.com wrote:
do we have a wiki/documentation about what exactly ended up in 5.4
from the Closure improvements? (Rebind)
https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope
is really hard to read, as it contains all of the suggested ideas and
possible solutions, etc.
if not, maybe someone with the required knowledge could start working
on adding the documentation?
I don't think so, but if I had to summarize the innovations in 5.4, this
would be it:
- Closures can now have an associated scope
- Closures can now have a bound object
- Closures can now be either static or non-static
- Closures defined in a place with an active scope are scoped accordingly
- Closures defined inside an instance method (or bound closure) have a
bound object (namely $this)
- Closures are static if defined within a static method or with the static
keyword (static function() { ... })
static = !bound
(but it's false that !static = bound)
bound = scoped
!static scoped = bound
(i.e., if !static, scoped = bound)
The bound instance and the scoped can be freely changed with Closure::bind
and $closure-bindTo, subject to these constraints.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
On Fri, Oct 07, 2011 at 08:13:49PM +0200, Hannes Magnusson wrote: When 5.3 came around, I literally had to diff the sources to figure out what was going on, I am not going through that again. ... If that doesn't happen, we wind up with more features like streams and filters which took 5+ years to document. The person making changes to the language needs to ensure those changes are documented. That can include either writing a first draft of the docs themselves and/or teaming up with someone on the documentation team. The most reliable thing to do is commit the php-src and phpdoc changes in one commit. At the very least, we could have a TODO file in phpdoc that contains a simple plain text explanation of the new functionality. You can say that I'm a dreamer..., --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
'
On Fri, Oct 7, 2011 at 8:58 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Fri, 07 Oct 2011 18:31:42 +0100, Ferenc Kovacs tyr...@gmail.com wrote:
do we have a wiki/documentation about what exactly ended up in 5.4
from the Closure improvements? (Rebind)
https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope
is really hard to read, as it contains all of the suggested ideas and
possible solutions, etc.
if not, maybe someone with the required knowledge could start working
on adding the documentation?
I don't think so, but if I had to summarize the innovations in 5.4, this
would be it:
- Closures can now have an associated scope
- Closures can now have a bound object
- Closures can now be either static or non-static
- Closures defined in a place with an active scope are scoped accordingly
- Closures defined inside an instance method (or bound closure) have a bound
object (namely $this)
- Closures are static if defined within a static method or with the static
keyword (static function() { ... })
static = !bound
(but it's false that !static = bound)
bound = scoped
!static scoped = bound
(i.e., if !static, scoped = bound)
The bound instance and the scoped can be freely changed with Closure::bind
and $closure-bindTo, subject to these constraints.
- Closures can now have an associated scope
as it is
https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope
?
at first I thought that scope means Variable scope, but I think I get
it now: it means that when the Closure calls/access something through
$this, it will be handled as it was called/accessed from the given
class(scope).
and this also explains why we had to add the third param for Closure::bind.
the bound param defines what is the $this pointing to, and the scope
means that from what scope would be used for accessing the $this.
having a static Closure means that it won't have the $this, but it can
still have a scope (so it can interact with other static methods).
thanks, I think I managed to wrap my head around that!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] little tweeking on the release process RFC
Hi I just read through the releaseprocess RFC( https://wiki.php.net/rfc/releaseprocess ) again, and I think that the part where we explain the Release Process and the BC could be clarified a little bit. (We still haven't agreed on the how many concurrent versions should we support, how long would be a version supported, doing LTS, etc. but thats another topic) No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis. I would re-phrase the No feature addition to changing existing behavior, as it now seems a little bit contradictional. Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6. Binary compatibility can be broken between two features releases, f.e. between 5.3 and 5.4: it is explained below this line, but maybe it would worth explicitly stating which BC are we referring to, as BC could also mean ABI/Binary compatibility which would again contradict the second sentence. for micro version, I would extend the bugfix part, for example the is_a fix can be called a bugfix, but large amount of code was depending on the buggy behavior hence the change affected a large amount of core out there, and the right behavior was achievable through other methods(using additional class_exists/interface_exists), so maybe we could mention some kind of rule for this. Backward compatibility must be kept (internals and userland) and ABI/API compatibility must be kept (internals) seems overlapping again. I think we should formalize the different kind of BCs, the following were mentioned in the RFC: - moving extensions from core to pecl (maybe also define adding new extensions, or moving from pecl to core) - internal src compatibility - internal ABI compatibility - internal API compatibility - userland API compatibility maybe it would be also a good thing to mention that the preferred way to break userland API compatibility is to first mark the feature/behavior as deprecated (documentation and/or E_DEPRECATED) and only remove it after that (which could only happen with a minor or major version by the RFC) plus the possible migration path should be also documented if possible. what do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: little tweeking on the release process RFC
- internal src compatibility oh, thats the same as internal API compatibility, then I'm not sure what src compatibility should be kept if possible, while breakages are allowed is referring to, as both internals API/ABI, and userland API is mentioned already in the rfc for the minor version. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 beta
On Fri, 07 Oct 2011 20:32:24 +0100, Ferenc Kovacs tyr...@gmail.com wrote: - Closures can now have an associated scope as it is https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope ? at first I thought that scope means Variable scope, but I think I get it now: it means that when the Closure calls/access something through $this, it will be handled as it was called/accessed from the given class(scope). Yes, sorry, by scope I mean EG(scope), which is a class entry, and, for the purposes relevant here, determines access to protected/private members. I did not want to convey its usual general meaning. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/mysqli/mysqli_api.c branches/PHP_5_4/ext/mysqli/mysqli_api.c trunk/ext/mysqli/mysqli_api.c
2011/9/19 Johannes Schlüter johan...@schlueters.de: On Mon, 2011-09-19 at 12:25 +0200, Ferenc Kovacs wrote: Good point, are you proposing to change code and make libmysql 5.0+ a requirement? If so, several changes should be made to ext/mysql, ext/mysqli and PDO_MySQL. I think that it is your call, but yes, I think it would reasonable, and it would make our/your work much easier if we would have to support fewer major versions. While we can't change requirements in bug fix versions (5.3.x) and not sure this is a good thing to do during beta (5.4) from other POV: beta is the last time to make such changes. but as I said, it is your call. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php54 vote
Hi https://wiki.php.net/todo/php54/vote I've just noticed that the php namespace and the primitive types (string, bool, int) are still not reserved. the primitive types didn't had the 66% of the votes, but the php namespace did, so at least that should have been reserved in 5.4 already. what is the status about that? -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
