+1 on unicode support. I think not having unicode support by default really hurts PHP in the enterprise where applications must almost always be internationalized. I know mbstring gets the job done, but it's really hard to evangelize PHP as a choice technology when you have to use an extension to do what Java and Perl do natively. I just sent an e-mail to the SOAP list on this subject on how strings are really not re-encoded to UTF-8-- so if you have a form that takes variables of any encoding and puts them through PEAR SOAP, they come out as ASCII (not good).
Btw, I had thought I read that mbstring was enabled by default after php 4.3.something-or-other. Is this true? The docs still say it's not enabled. +1 on enhanced serialization. One thing we've been looking at is the performance enhancing products (ZPS, APC, TMMC) for both performance and storing variables in memory. A high performing mechanism to keep variables in memory, persist objects between requests, and serialize objects for use in multiple scripts is essential in my opinion. Also, how would this play with JSR-223? Regards, Al Baker On Thu, 2004-10-21 at 23:45 +0100, Wez Furlong wrote: > > 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 >
