Re: [PHP-DEV] Questions regarding DateTimeImmutable
Am 15.02.2013 21:49, schrieb Nikita Popov: a) The DateTimeImmutable class extends the DateTime class. Why was this done this way? Both classes are incompatible (as in the inheritance violates LSP). E.g. if you hint against DateTime, then passing in DateTimeImmutable will not work (as the behavior is different). The same also applies the other way around (DateTime extending DateTimeImmutable). Imho a mutable and an immutable variant of a class can't reasonably extend from one another, so I'm not sure why this was done. I raised the same question to Derick and he said that it had to be done this way because of BC issues. The way it is implemented right now makes no sense to me at all. Thank you, Nikita, for bringing this to the attention of this list. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Debug build with shared pdo_mysql module
Hi, our default PHP package includes pdo_mysql as a shared module. Creating a debug build with the same configuration seems to be impossible due to bug #60840. This bug was closed as Not a bug but it is not clear how this should be solved. Why does it only break if --enable-debug is passed and works fine without? Am I missing something obvious here? Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Configure fails due to different behavior in new versions of pkg-config
Hi, since pkg-config 0.28 pkg-config --cflags-only-I openssl returns an empty string and not a single space like it did in the previous versions. This breaks the configure script of PHP when called with ./configure --with-imap --with-imap-ssl. The relevant snippet from the configure script is: ... OPENSSL_LIBS=`$PKG_CONFIG --libs openssl` OPENSSL_INCS=`$PKG_CONFIG --cflags-only-I openssl` ... if test -n $OPENSSL_LIBS test -n $OPENSSL_INCS; then ... I am not sure why we are testing for content in $OPENSSL_INCS anyway. Am I correct that removing test -n $OPENSSL_INCS from configure is the correct fix here (and in general)? Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
-Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Saturday, February 16, 2013 12:54 AM To: Zeev Suraski Cc: PHP internals Subject: RE: [PHP-DEV] Zend Optimizer+ Source Code now available Hi Zeev, I think people are keen to see Optimizer+ merged. Hopefully the RFC can set expectations clear on what the short-term steps will be, and what the bigger picture might look like. The middle-term tasks will then work themselves out as we get to them (in true PHP fashion) - What does Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for it mean? Does it mean: * Work really had to get it into PHP 5.5.0 with no delay to 5.5? * Include it in /ext as-is, i.e. perhaps no ZTS support, or marked EXPERIMENTAL? * Include it in PHP 5.5.x where x 0, when Optimizer+ is complete? The slippage of 5.5 is an issue to some people, so clarity here would be good. It's in the context of this, one paragraph above it: The question on the table is whether most users would prefer a slightly later release with an out-of-the-box working opcode cache, or a slightly earlier release without a compatible opcode cache available for several additional months. In other words, this option mean that if we can't integrate it without delaying 5.5.0, we don't integrate it. By integration I refer to including something that is production quality, potentially enabled-by-default (TBD), that everyone should feel comfortable using. I believe the wider community is expecting the op-code cache to just work, so if that's not the case, the RFC should communicate this clearly. There's also the potential to damage Zend's reputation if what is released doesn't work well. I agree, although an opcode cache does add an extra layer of complexity, so it does stand the chance to break otherwise working setups (the same can happen with other opcode caches). It should be a rare occurrence, with the performance advantage far outweighing it. - What are your general thoughts about its integration architecture and the potential for alternative op-code caches to be used? I know code can always be changed, but what (if any) design will happen from the start to make this easy? I'm not sure. The level of integration we're talking about for 5.5.0, due to the haste, is not going to be beyond a mostly soft-bundle, at most something that gets enabled by default - but can still be disabled or outright removed. That means that you should be able to replace it with any other opcode cache you might want. However, for the future, there *might* be potential for further gains we might be able to get from tighter integration between the different layers. At this point I don't have any concrete ideas, though, so it's possible it's only theoretical. Regardless, such tighter integration - that would preclude other opcode caches from being used - will have to be the subject of a separate RFC vote. I'll clarify that point too in the RFC. - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/16/2013 11:16 AM, Zeev Suraski wrote: - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) I don't think I would ever get neither the spelling nor the pronunciation of Cachze right. I like the much simpler opcache name. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
Hi! a) The DateTimeImmutable class extends the DateTime class. Why was this done this way? Both classes are incompatible (as in the inheritance They're not really incompatible. Functions that do not modify dates would work just fine. So it's not 100% compatible, which is not the same as incompatible. Of course, we could instead create DateTimeBaseAbstractClass, but IMHO rewriting all your code to support it wouldn't be worth the trouble for 99.9% of the code, so what would end up happening that nobody could use DateTimeImmutable with any existing code that expects DateTime. I personally don't see much point in DateTimeImmutable anyway (immutable data structures are very important for concurrent programs but for PHP I don't see much benefit) but if people need it, fine. But ask yourself a question - do you really want to rewrite every library that accepts DateTime as an argument in order to use DateTimeImmutable? b) The DateTimeImmutable class is (method-wise) an exact copy of DateTime. This makes for some rather weird method names for an immutable object. E.g. there is DateTimeImmutable::modify, which to me seems quite contradictory. There are also a lot of methods of the DateTimeImmutable::setTime form, which also seems rather odd and confusing (how can I set something on an immutable object?) I don't see how it's so hard to grasp - it sets time and returns the modified object. I can't believe you genuinely don't understand how it works. I have a feeling this confusing argument in getting somewhat stale: PHP users - especially those that want to use specially designed classes that are useable only in context of design of non-trivial complexity - have sufficient brain capacity to understand what setTime could do. And if they absolutely can't, they can to the unthinkable - read the manual. So I can see the LSP argument - but confusing argument really doesn't seem to apply here. -- 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] Bug hunt
As we are nearing the final push for the 5.5 release pending the opcode cache question, could we do a bug killing push please? We have quite a few old open bugs sitting around that would be good to take a second look at. Either search https://bugs.php.net for open bugs in the areas that interest you or just keep hitting https://bugs.php.net/random until you get one you think you can add something useful to. Even if you can't necessarily fix it, simply checking to see if the bug is still reproducable/relevant is valuable information for us. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
