Re: Unicode-compatible extensions (was Re: [PHP-DEV] type hinting throwing a fatal error)

As Zeev stated it's additional thread-storage fetching and passing an extra parameter. However, it's a marginal difference so I wouldn't base my architectural decision on that. It was only regarding performance decision. I wouldn't base my architecture decision solely based on performance but also stability and ease-of-deployment and management. Andi At 12:17 AM 8/25/2005, Marcus Boerger wrote:

Hello Andi, wow, now that makes me wonder if you perhaps also know a reason for? I mean in theory it should be faster shouldn't it? Or is the problem that we far to often use TRSMLS_FETCH() with all its disadvantages? best regards marcus Thursday, August 25, 2005, 1:28:49 AM, you wrote: Marcus, You will most likely find that the "faster" Apache way with thread-safe PHP is slower than the slower Apache way with non-thread-safe PHP. And even FastCGI will be faster :) Andi At 12:25 PM 8/24/2005, Marcus Boerger wrote:

Hello John, Wednesday, August 24, 2005, 5:22:07 PM, you wrote:

On Wed, 2005-08-24 at 17:41 +0300, Zeev Suraski wrote:

Maybe we can give extensions a way to indicate that they're Unicode compatible, and assume they're not if they don't. Non-compatible extensions will not be loaded and produce an error.

Not to hijack the topic, but if we are going to do something like this why not also provide these sorts of flags for things like extensions and thread safety?

Even though a change in an external lib or a commit in our source might change this - i see those cases very rarly and typically detected by the maintainers easily. Our code is threadsafe and most libs are, too. The other thing is the advantage and that is very big to my guesses since it would allow us to go with the faster apache way finally. So i like this idea pretty much.