todo items - Externals

18 years ago by Lukas Kahwe Smith — view source

unread

Hello,

On the heels of the 5.2.1 release I just wanted to bring up the
following todo items that have been on the 5.x todo lists since ages.
Are these still alive? Have they been done? What would be a sensible
target version?

Especially the "on-the-fly static properties" is much requested.

Open for discussion

1. on-the-fly static properties (mike)
2. 'strict class' to disable dynamic member variable addition (marcus)
3. add a function that returns tsrm_thread_id() - already covererd

by zend_thread_id() but only in debug ZTS mode (Wez)
4. userspace streams filter that acts as a default filter through
which require/include read their files (Sebastian, Sara)
5. pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control support"

Todo items for future 5.Y.Z releases

1. Switch for disabling/enabling materialized cursors in mysqli (georg)
2. add support for files >2GB (wez)
3. add array_replace[_recursive] (diff, phpt) (matt)
4. PDO
      1. allow the DSN to be passed as array, proposal phase. An

initial proposal was done here (pierre, lukas)
5. XMLWriter:
1. Add writeNode([xmlreader obj]), allow to create a push/pull
parser

regards,
Lukas

18 years ago by Michael Wallner — view source

unread

Lukas Kahwe Smith wrote:

on-the-fly static properties (mike)

I didn't request these, I just posted something that looked like a patch.
Yet, I wouldn't mind removing another unreasonable fatalism.

'strict class' to disable dynamic member variable addition (marcus)

IIRC that doesn't describe the whole problem, re: OO-strictness@internals etc.

add support for files >2GB (wez)

That would really be nice!

Regards,

Michael

18 years ago by Lukas Kahwe Smith — view source

unread

Michael Wallner wrote:

on-the-fly static properties (mike)

I didn't request these

FYI, the names in parenthesis are the person I figured was most likely
to implement the given feature and not who requested it necessarily.
Anyways, a lot of people "abuse" the comment system on the todo wiki for
feature requests, and the above item has been by far the most requested one.

Personally I would really like to see it as well. It would open up a lot
of possibilities, for example in DOA/ActiveRecord implementations.

regards,
Lukas

18 years ago by Ilia Alshanetsky — view source

unread

on-the-fly static properties (mike)

It was already discussed on the mailing list in the past and declined.

'strict class' to disable dynamic member variable addition
(marcus)

Possible for 5.3, or PHP 6 but definitely not 5.2

add a function that returns tsrm_thread_id() - already
covererd by zend_thread_id() but only in debug ZTS mode (Wez)

I suppose it could be added to 5.2 if someone has a non-intrusive patch.

userspace streams filter that acts as a default filter
through which require/include read their files (Sebastian, Sara)

Possible for 5.3

pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support"

The patch is where?

Switch for disabling/enabling materialized cursors in mysqli
(georg)

add support for files >2GB (wez)

add array_replace[_recursive] (diff, phpt) (matt)

Possible for 5.3

PDO

allow the DSN to be passed as array, proposal phase. An
initial proposal was done here (pierre, lukas)

Probably not.

XMLWriter:

Add writeNode([xmlreader obj]), allow to create a push/
pull parser

Possible for 5.3

Ilia Alshanetsky

18 years ago by Lukas Kahwe Smith — view source

unread

Ilia Alshanetsky wrote:

on-the-fly static properties (mike)

It was already discussed on the mailing list in the past and declined.

Hmm I will search the archives, but I am not aware that this was declined.

regards,
Lukas

18 years ago by Lukas Kahwe Smith — view source

unread

Lukas Kahwe Smith wrote:

Ilia Alshanetsky wrote:

on-the-fly static properties (mike)

It was already discussed on the mailing list in the past and declined.

Hmm I will search the archives, but I am not aware that this was declined.

Err .. sorry .. I got confused. I misread on-the-fly static properties
to be late static binding. So forget all about what I said regarding
on-the-fly static properties.

But do note that late static binding would be greatly appreciated.

regards,
Lukas

18 years ago by Derick Rethans — view source

unread

Lukas Kahwe Smith wrote:

Ilia Alshanetsky wrote:

on-the-fly static properties (mike)

It was already discussed on the mailing list in the past and declined.

Hmm I will search the archives, but I am not aware that this was declined.

Err .. sorry .. I got confused. I misread on-the-fly static properties to be
late static binding. So forget all about what I said regarding on-the-fly
static properties.

But do note that late static binding would be greatly appreciated.

Yes, but that'd be something for 6 i think.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

18 years ago by Lukas Kahwe Smith — view source

unread

Derick Rethans wrote:

But do note that late static binding would be greatly appreciated.

Yes, but that'd be something for 6 i think.

I just nocticed its already on the php6 todo list as:
re-use the "static::" keyword to do runtime evaluation of statics.

http://oss.backendmedia.com/PhP60

For the rest of the points I have updated the PHP5.2 and PHP 5.3 todo
lists according to Ilia's comments:
http://oss.backendmedia.com/PhP52
http://oss.backendmedia.com/PhP53

regards,
Lukas

18 years ago by Lukas Kahwe Smith — view source

unread

Ilia Alshanetsky wrote:

pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support"

The patch is where?

http://marc.theaimsgroup.com/?l=php-dev&m=115635520414869&w=2

I should have mentioned that many of the items have links that are
listed on the PHP 5.2 todo page:
http://oss.backendmedia.com/PhP52

regards,
Lukas

18 years ago by Steph Fox — view source

unread

Ilia,

http://devzone.zend.com/node/view/id/1432 is the new PAT directory. I know
it's not very catchy -
http://devzone.zend.com/public/view/tag/Weekly_Summaries will generally find
it.

The top four are dead links at present pending a permissions issue getting
itself resolved. The rest work.

Those LDAP patches are from Pierangelo Maserati, who is part of the OpenLDAP
dev team. I guess he probably knows his stuff :) but they're pretty old (end
2005).

Steph

----- Original Message -----
From: "Lukas Kahwe Smith" mls@pooteeweet.org
To: "Ilia Alshanetsky" ilia@prohost.org
Cc: "internals Mailing List" internals@lists.php.net
Sent: Friday, February 09, 2007 2:06 PM
Subject: Re: [PHP-DEV] todo items

Ilia Alshanetsky wrote:

pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support"

The patch is where?

http://marc.theaimsgroup.com/?l=php-dev&m=115635520414869&w=2

I should have mentioned that many of the items have links that are listed
on the PHP 5.2 todo page:
http://oss.backendmedia.com/PhP52

regards,
Lukas

18 years ago by Chris Stromsoe — view source

unread

pat3 and pat44 are now pat18 and pat19. I've been patching them in by
hand. I've been using them since they were originally posted in December
of 2005. They work fine up through the 5.1.x releases. I will be
patching a 5.2.x deployment with them within the next 2 or 3 weeks.

http://devzone.zend.com/content/patch/pat18.txt
http://devzone.zend.com/content/patch/pat19.txt

-Chris

Ilia,

http://devzone.zend.com/node/view/id/1432 is the new PAT directory. I
know it's not very catchy -
http://devzone.zend.com/public/view/tag/Weekly_Summaries will generally
find it.

The top four are dead links at present pending a permissions issue
getting itself resolved. The rest work.

Those LDAP patches are from Pierangelo Maserati, who is part of the
OpenLDAP dev team. I guess he probably knows his stuff :) but they're
pretty old (end 2005).

Steph

----- Original Message ----- From: "Lukas Kahwe Smith" mls@pooteeweet.org
To: "Ilia Alshanetsky" ilia@prohost.org
Cc: "internals Mailing List" internals@lists.php.net
Sent: Friday, February 09, 2007 2:06 PM
Subject: Re: [PHP-DEV] todo items

Ilia Alshanetsky wrote:

pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support"

The patch is where?

http://marc.theaimsgroup.com/?l=php-dev&m=115635520414869&w=2

I should have mentioned that many of the items have links that are listed
on the PHP 5.2 todo page:
http://oss.backendmedia.com/PhP52

regards,
Lukas

18 years ago by Steph Fox — view source

unread

Ah cool!

If you could post your update or updates (as the case may be) as a tarball,
.txt file or download link on this list 'twould be good. If you have the
time and energy to maintain ext/ldap, 'twould be even better, but if that's
not an option I can at least check that your changes compile against PHP_5_2
latest and update the PAT version(s).

There's a directory containing a few test scripts - ppolicy, pagedResults,
whoami, exop - in the tarball on Pierangelo's site (linked from PAT
homepage), but I doubt they're generic enough to be used in the PHP test
suite as they stand. Could you please look into that, or provide some usable
test scripts (.phpt) alongside your updates?

this has been one of the main sticking points in the past. PHP/LDAP users
don't have a framework for testing the extension or for reporting bugs in a
meaningful way without them.

Thanks Chris!

Steph

pat3 and pat44 are now pat18 and pat19. I've been patching them in by
hand. I've been using them since they were originally posted in December
of 2005. They work fine up through the 5.1.x releases. I will be
patching a 5.2.x deployment with them within the next 2 or 3 weeks.

http://devzone.zend.com/content/patch/pat18.txt
http://devzone.zend.com/content/patch/pat19.txt

-Chris

Ilia,

http://devzone.zend.com/node/view/id/1432 is the new PAT directory. I
know it's not very catchy -
http://devzone.zend.com/public/view/tag/Weekly_Summaries will generally
find it.

The top four are dead links at present pending a permissions issue
getting itself resolved. The rest work.

Those LDAP patches are from Pierangelo Maserati, who is part of the
OpenLDAP dev team. I guess he probably knows his stuff :) but they're
pretty old (end 2005).

Steph

----- Original Message ----- From: "Lukas Kahwe Smith"
mls@pooteeweet.org
To: "Ilia Alshanetsky" ilia@prohost.org
Cc: "internals Mailing List" internals@lists.php.net
Sent: Friday, February 09, 2007 2:06 PM
Subject: Re: [PHP-DEV] todo items

Ilia Alshanetsky wrote:

pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support"

The patch is where?

http://marc.theaimsgroup.com/?l=php-dev&m=115635520414869&w=2

I should have mentioned that many of the items have links that are
listed on the PHP 5.2 todo page:
http://oss.backendmedia.com/PhP52

regards,
Lukas

18 years ago by Nico Sabbi — view source

unread

Lukas Kahwe Smith wrote:

Hello,

On the heels of the 5.2.1 release I just wanted to bring up the
following todo items that have been on the 5.x todo lists since ages.
Are these still alive? Have they been done? What would be a sensible
target version?

Especially the "on-the-fly static properties" is much requested.

Open for discussion

on-the-fly static properties (mike)

'strict class' to disable dynamic member variable addition (marcus)

add a function that returns tsrm_thread_id() - already covererd
by zend_thread_id() but only in debug ZTS mode (Wez)

userspace streams filter that acts as a default filter through
which require/include read their files (Sebastian, Sara)

pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support"

may I re-propose the attached patch? The first time it was ignored, but
the current behaviour of
dom module is extremely annoying

18 years ago by Christian Stocker — view source

unread

may I re-propose the attached patch? The first time it was ignored, but
the current behaviour of
dom module is extremely annoying

Completely out of context your post, but I was the one who wrote that
part of code, since I was more or less forced to implement it the way it
is.

I'm fine with removing it, but there were big objections against the
whole recover stuff back then when I committed it, so the way it works
currently was some kind of compromise

and don't forget the comments :)

Unfortunately, I couldn't find the posts regarding this matter in the
archives.

chregu

--- ext/dom/document.c.orig 2006-01-01 13:50:06.000000000 +0100
+++ ext/dom/document.c 2006-11-03 10:53:18.000000000 +0100
@@ -1512,18 +1512,11 @@
#endif

ctxt->recovery = recover;
if (recover) {
old_error_reporting = EG(error_reporting);
EG(error_reporting) = old_error_reporting | E_WARNING;
}

xmlParseDocument(ctxt);

if (ctxt->wellFormed || recover) {
ret = ctxt->myDoc;
if (ctxt->recovery) {
	EG(error_reporting) = old_error_reporting;
}
/* If loading from memory, set the base reference uri for the document */
if (ret->URL == `NULL` && ctxt->directory != NULL) {
	ret->URL = xmlStrdup(ctxt->directory);

18 years ago by nico — view source

unread

Christian Stocker wrote:

may I re-propose the attached patch? The first time it was ignored, but
the current behaviour of
dom module is extremely annoying

Completely out of context your post, but I was the one who wrote that
part of code, since I was more or less forced to implement it the way it
is.

I'm fine with removing it, but there were big objections against the
whole recover stuff back then when I committed it, so the way it works
currently was some kind of compromise

See also:
http://blog.bitflux.ch/archive/2004/08/13/parsing_non_well_formed_xml_documents_in_php.html
http://blog.bitflux.ch/archive/2004/08/20/parsing_non_well_formed_xml_documents_considered_harmful.html

and don't forget the comments :)

I see, but in my opinion since the recover mode is off by default and
E_WARNING is on by default, if recover mode is explicitly activated
php should respect the developer's need to keep the interpreter as quiet
as possible.
A developer with more stringent needs will either keep recover mode off
or activate it alongside with E_WARNING.

BTW, I've seen thousand of xml docs declared "broken" not for syntax
errors, but
for the simple presence of characters not corresponding the the encoding
specified...

Nico

18 years ago by Rob Richards — view source

unread

nico wrote:

I see, but in my opinion since the recover mode is off by default and
E_WARNING is on by default, if recover mode is explicitly activated
php should respect the developer's need to keep the interpreter as
quiet as possible.
A developer with more stringent needs will either keep recover mode off
or activate it alongside with E_WARNING.
If someone actually has a reason to use recover mode, then they probably
would be using libxml_use_internal_errors(TRUE) as well.
It is painful (maybe not enough) to use recover mode for a reason.

BTW, I've seen thousand of xml docs declared "broken" not for syntax
errors, but
for the simple presence of characters not corresponding the the
encoding specified...
And that somehow makes it any better than having syntax errors?

Rob