Hello Andi, i want typehinting with arrays and ifsetor in 5.1.
Also i still think we should change the way objects work: The stored objects should know their classentry and have a pointer to the handlers. That should speed up everything related to objects. The only thing it won't allow is storing instances of the same class in different object storages. But for now there is only one and the only way we might get more is having an application server and there we need other solutions anyway because there we'd have the same problems with the classentries. best regards marcus Friday, October 22, 2004, 9:05:32 AM, you wrote: > 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. -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
