# to be discussed items - Thread: https://externals.io/message/38944 - Original archive: https://news-web.php.net/php.internals/38944 - Started by Lukas Kahwe Smith on 2008-07-14T12:58:13+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38944 — Lukas Kahwe Smith — 2008-07-14T12:58:13+00:00 URL: https://externals.io/message/38944#38944 Hi, I am about to move all "to be discussed items" [1] to the future PHP release section (so after 5.3): 1) userspace streams filter that acts as a default filter through which require/include read their files (Sebastian, Sara) 2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a push/ pull parser 3) add a function that returns tsrm_thread_id() - already covered by zend_thread_id() but only in debug ZTS mode (Wez) 4) DOM recover error reporting mode 5) PDO: allow the DSN to be passed as array, proposal phase. An initial proposal was done here (pierre, lukas) 6) namespaces for internal classes 7) deprecate/remove ticks 8) Algorithm Optimizations - string search For 6) it does not seem like we know a good solution at this stage. For 8) we might decide to selectively incorporate patches. Though it would be the authors job to present us two RMs with easy to evaluate candidate patches to consider. regards, Lukas Kahwe Smith mls@pooteeweet.org [1] http://wiki.php.net/todo/php53#to_be_discussed --- ## #38947 — Stanislav Malyshev — 2008-07-14T18:40:12+00:00 URL: https://externals.io/message/38944#38947 · In reply to: #38944 Hi! > For 6) it does not seem like we know a good solution at this stage. For I think we need to gather some experience on namespace usage before we move internal classes to them. Also, this change would be binary and source-code compatible (we'll keep the old names in 5.x for sure) so we have no BC problem here - we may start it whenever we wish to. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #38948 — david.zuelke@bitextender.com — 2008-07-14T20:09:41+00:00 URL: https://externals.io/message/38944#38948 · In reply to: #38947 +1 Am 14.07.2008 um 20:40 schrieb Stanislav Malyshev: > Hi! > > > […] > > I think we need to gather some experience on namespace usage before > we move internal classes to them. Also, this change would be binary > and source-code compatible (we'll keep the old names in 5.x for > sure) so we have no BC problem here - we may start it whenever we > wish to. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #38950 — Marcus Boerger — 2008-07-14T21:15:48+00:00 URL: https://externals.io/message/38944#38950 · In reply to: #38944 Hello Lukas, Monday, July 14, 2008, 2:58:13 PM, you wrote: > Hi, > I am about to move all "to be discussed items" [1] to the future PHP > release section (so after 5.3): > 1) userspace streams filter that acts as a default filter through > which require/include read their files (Sebastian, Sara) I don't care but want to remind that the user streams do not in the slightest folloow any name scheme whatsoever. So I rather have them ripped and reimplemented. > 2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a push/ > pull parser should be easy enough and is simply a new function in an ext, can't just somebody do it? > 3) add a function that returns tsrm_thread_id() - already covered by > zend_thread_id() but only in debug ZTS mode (Wez) Iirc the last time we discussed it we saw it to be a debug only function. > 4) DOM recover error reporting mode > 5) PDO: allow the DSN to be passed as array, proposal phase. An > initial proposal was done here (pierre, lukas) Can we first decide whether this effort is worth anything (as in whether we reimplement the whole extension)? > 6) namespaces for internal classes The general idea so far was that the user should namespace their names and PHP uses the global name space. Just as in any other language. However that does not mean that some ext could have namespaces. But given that until now we lived without we would make it much harder for users if now we would put all (or even any tiny bit of) internal functionality inside namesoace. Just because everything has to be done twice then from the user perspective. So this is contraproductive. It would also take away the freedom to ignore namespaces. > 7) deprecate/remove ticks Deprecate, as this is a minor version and not a major version. If we remove them which personally I'd love to do, then we should drop tons of other deprecated stuff as well and get rid of the stupid no removing unless major version change rule. > 8) Algorithm Optimizations - string search Anythign that makes PHP faster should always be welcome. Unless: - comes with API additions -> RM decision - internal API change -> next minor version - extenal API change -> next major verision Best regards, Marcus --- ## #38952 — Andrey Hristov — 2008-07-15T11:08:54+00:00 URL: https://externals.io/message/38944#38952 · In reply to: #38944 Lukas Kahwe Smith wrote: > Hi, > > I am about to move all "to be discussed items" [1] to the future PHP > release section (so after 5.3): > > 1) userspace streams filter that acts as a default filter through which > require/include read their files (Sebastian, Sara) > 2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a > push/pull parser > 3) add a function that returns tsrm_thread_id() - already covered by > zend_thread_id() but only in debug ZTS mode (Wez) Regarding this, PHP is not pthreads conformant. The thread_id has own type and it is implementation specific. There is pthread_equal() to make comparison, although it is not used in the PHP code and the thread id is considered to be an int, last time I checked. > 4) DOM recover error reporting mode > 5) PDO: allow the DSN to be passed as array, proposal phase. An initial > proposal was done here (pierre, lukas) > 6) namespaces for internal classes > 7) deprecate/remove ticks > 8) Algorithm Optimizations - string search > > For 6) it does not seem like we know a good solution at this stage. For > 8) we might decide to selectively incorporate patches. Though it would > be the authors job to present us two RMs with easy to evaluate candidate > patches to consider. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > [1] http://wiki.php.net/todo/php53#to_be_discussed > Best, Andrey --- ## #38953 — Pierre Joye — 2008-07-15T11:25:44+00:00 URL: https://externals.io/message/38944#38953 · In reply to: #38950 hi Marcus, > > […] > > should be easy enough and is simply a new function in an ext, can't just > somebody do it? It is not hard but not a small thing either (nested elements, attributes, etc.). It could accept a DOM node as well. However I will not have the time to do it before the 24th so if anyone is interested, please raise the hand :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38954 — Lukas Kahwe Smith — 2008-07-15T11:26:59+00:00 URL: https://externals.io/message/38944#38954 · In reply to: #38953 > hi Marcus, > > On Mon, Jul 14, 2008 at 11:15 PM, Marcus Boerger > wrote: > > > […] > > It is not hard but not a small thing either (nested elements, > attributes, etc.). It could accept a DOM node as well. > > However I will not have the time to do it before the 24th so if anyone > is interested, please raise the hand :) traditionally we have also added new non BC breaking features in the first couple patch releases. So stuff like this could also just wait for 5.3.x (where 0 < x < 5). so in this context "future php releases" means any php release after 5.3.0 regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38956 — Rob Richards — 2008-07-15T12:16:19+00:00 URL: https://externals.io/message/38944#38956 · In reply to: #38944 Hi Lukas, Lukas Kahwe Smith wrote: > Hi, > > I am about to move all "to be discussed items" [1] to the future PHP > release section (so after 5.3): > 2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a > push/pull parser I also don't think I would be able to find the time to get this done in the next week. Probably a 5.3.x feature. > 4) DOM recover error reporting mode I don't agree with this one at all. The libxml_use_internal_errors function can be used to suppress errors. I'd prefer to drop this one completely. Rob