Re: [PHP-DEV] Why not attach XMLReader / XMLWriter to open php streams?
Hans-Peter Oeri wrote: Hi! As documented - and several searches did not lead to a different result - XMLReader and XMLWriter can only work on an URI. That would be a php stream opened and closed by themselves. For several workflows, e.g. with php://temp, it would be nice to be able to attach XMLReader/XMLWriter to a pre-opened php stream. I would describe it as letting them work on a stream instead of on an uri. As I didn't find anything about it: Is there a reason for not supporting 'stream resources'? Other extension, like e.g. curl, do. HPO There never was a real need for this. Can easily be done by creating your own stream wrapper and feeding the already opened streamed through it. Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. Melanie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org Sure, you can create an empty interface for this scenario but only for self defined classes. All PHP classes can't used with this interface. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18.06.2010, at 18:13, Christian Kaps wrote: On Fri, 18 Jun 2010 16:28:31 +0200, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 18.06.2010, at 16:13, Melanie Rhianna Lewis wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. isnt this what interfaces are for? regards, Lukas Kahwe Smith m...@pooteeweet.org Sure, you can create an empty interface for this scenario but only for self defined classes. All PHP classes can't used with this interface. and you seriously need type hints for this use case? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On 18 June 2010 15:13, Melanie Rhianna Lewis cybersp...@php.net wrote: On 17 Jun 2010, at 20:14, Stas Malyshev wrote: Hi! I know the discussion is about scalar type hints. But what is with a object type hint as base for all objects? When it makes sense to accept any object, regardless of the class, but not other types? I wonder if it's really a common use-case. Its useful in some patterns. For example suppose you have a pattern where a class wraps another class. The wrapped class could be *any* class if you're modify the behaviour of some default methods (say doing something like a decorator pattern). Having a type hint that recognises object vs non objects is useful. Melanie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php class::method(object $instance) would certainly be useful. Could this not be solved by internally extending all userland classes (and whilst we are at this why not all internal classes) from a PHP supplied empty class? Maybe stdClass? scalar, array, class, interface, untyped class. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Remove sqlite2 from trunk
On Thu, 2010-06-17 at 18:43 -0400, Mike Robinson wrote: On June-17-10 12:44 PM Pierre Joye wrote: The only voice that matters here is the voice of the mysql team, they know if it is still widely used or not, and how :) The voice that matters is internals at large. Really? Seriously, how could they reliably know that? :) I still like the I would be against that, notwithstanding. As I said before in this thread: Realistically we can't drop it. Too many tutorials, books, applications, ... mention mysql_* and ignore the limitations and issues the old mysql extension provides... Johannes -- Johannes Schlüter MySQL Engineering Connectors and Client Connectivity Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht München: HRB161028 Geschäftsführer: Jürgen Kunz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Remove sqlite2 from trunk
On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote: drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. I'm all for starting to use sqlite3 but I found two issues with the migration to the new api: a) sqlite_busy_timeout is not available in sqlite3.c This is important for an application to return a failure right away instead of wait for locks to be release. The patch looks simple since it's a wrapper for SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); b) No persistent connections Any reason why it wasn't migrated from sqlite.c? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
On Jun 18, 2010, at 10:50 AM, Jonathan Bond-Caron wrote: On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote: drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3 extensions. The sqlite2 library is no longer maintainer and the migration path from version 2 to 3 is very simple. Unless there any objections, I'd like to make this happen in the next week or two. I'm all for starting to use sqlite3 but I found two issues with the migration to the new api: a) sqlite_busy_timeout is not available in sqlite3.c This is important for an application to return a failure right away instead of wait for locks to be release. The patch looks simple since it's a wrapper for There is a patch going around, someone should commit it or I will. SQLITE_API int sqlite3_busy_timeout(sqlite3*, int ms); b) No persistent connections Any reason why it wasn't migrated from sqlite.c? Persistent connections make sense if there is an actual overhead in creating a socket etc, it doesn't really apply and is actually more dangerous if something is left unfinished and locks the DB. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove sqlite2 from trunk
Johannes Schlüter schrieb: As I said before in this thread: Realistically we can't drop it. Too many tutorials, books, applications, ... mention mysql_* and ignore the limitations and issues the old mysql extension provides... True, true... One of the best things one can do is to bash very article, blog posting, mailinglist posting and in particular every recent book showing ext/mysql examples instead or either ext/mysqli or PDO_MySQL examples. Every now and then we get feature requests for ext/mysql through bug reports. The reporters often complain badly if we MySQL guys refuse to add the requested feature to ext/mysql ... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
