It sounds to me that it makes sense to split the roadmap into two. Probably something like:
PHP 5.1:
- Improved VM
- PDO
- Possibly improved serialization
- Other minor changes in language and extension
PHP 5.2: - Better support for i18n - int64
This is obviously just a general idea and I'm sure there are other things.
As I discussed with Derick today, I think i18n is something where work can commence ASAP (even before 5.1) but my guess is that it would take quite a bit of time for it to be release ready. Having the new VM and PDO out there earlier makes sense IMO. We just need PDO docs :)
Good luck with the move Wez!
Andi
At 11:45 PM 10/21/2004 +0100, Wez Furlong wrote:
> a) PDO support for most popular DBs. Maybe you can give a status report of > where PDO is today and how much work it still requires? If it requires a > lot of work maybe more people can join the effort. Also is there an online > phpDoc of each DB API one can look at? I've looked at the source code and > at the functionality and it's pretty good but I'll definitely try and look > deeper as we get closer to 5.1.
Feature-wise, it's missing scrollable (eg: random access) cursors and Marcus' iterators (sorry Marcus). We also discussed a change in the error codes to match the standard SQLSTATE codes found in ODBC. There could be a couple of other bits and pieces that I've forgotten for the moment, but nothing major. None of these are particularly huge tasks; a couple of days good hacking will have them wrapped up.
Aside from that, PDO is very usable for the most common data access patterns that you are likely to use in PHP.
Driver wise, we have a nice collection. The only major driver that we are missing is mysql 4.x (we have 3.x).
Documentation-wise, a couple of people I spoke to in Toronto offered to write some docs for PDO, but I haven't heard any news on this yet.
> b) New VM architecture, some other core engine changes which have happened
> since 5.0.x.
> c) Polish some left overs in the OO model from 5.0.x, mainly the access
> modifiers (if/when they are allowed to be used). For example, in interfaces
> they shouldn't be used. Probably some error handling and bug reports which
> still require attention.
> d) Finalize the few tiny new features request on the language level from 5.1.
- int64_t support in zvals... or some other way of natively handling larger integers without having to dip into floats. I'd prefer the former; this is something that is getting more important now that we have more and more extensions that use 64bit values; mostly database extensions, but also large file support could do with a 64bit type.
- large file support in streams. Been discussing this with Edin and Stig recently; the changes are not major, although we would really benefit from a 64bit type for the stat() related functions.
This next one is likely to be controversial, but I think we should give it some thought:
- unicode support for strings. Tricky topic this one. It would be nice to have some kind of engine level support, but I can't think of a nice way to do it that won't break existing scripts.
Instead, it would be nice if we had some kind of "String" class (would be nice to use that as the class name...) that used the overloading features of the engine to make it smell like a regular string. It would be aware of, at least, the most common charset encodings (and perhaps be able to load in tables for others at runtime) and have methods to concatentate, split, index by character position (not byte position) etc. etc. and handle differences in character encodings transparently.
This can be developed as a PECL extension for now, but once it matures it would be very nice to see it in the default distribution. I believe that Derick is working on code for transliteration (that just went into PECL CVS) that could also be folded into this.
Another tricky topic (implementation wise; the serializer code is nasty):
- a better serialization interface for objects. It would be *very* nice if we had a more flexible API to cater for the serialization interfaces found in COM, Java, .Net, Corba etc. While we're at it, maybe we can fix the really poor performance issue I mentioned a while back; it was massively faster to var_export() and eval() a large array than it was to serialize() and deserialize() it.
> Depending on the status of PDO it'd be good to have some timeframe for RC1 > just so that we have some soft date to work towards.
I move to USA in a week, so the next 2 weeks are going to be a bit busy for me, but I should have a bit more hacking time after the move; PDO should be wrapped up really soon.
--Wez.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
