Re: [PHP-DEV] Re: PHP Unicode support design document

Andrei Zmievski wrote: Is there any way to keep the byte semantics (in oppose to unicode semantics) only for the existing functions? For example, the Oracle 8 functions can be configured to use utf-8 for the character encoding of strings. In order for them to work properly, fundamental functio

[PHP-DEV] PHP 6.0 Wishlist

I just joined this list and caught this thread (no suggestions like this in the archive)... For v6.0... how about allowing comparison operator expressions like the following: if (2 < $x <= 4) {} I prefer this concise way as it is common for mathematics expressions, and much easier to gra

Re: [PHP-DEV] Schroedinger Objects

Yep I think that's a good point. Checking for cast is the right thing IMO. At 02:45 PM 8/24/2005, Rasmus Lerdorf wrote: As per bug #34199 and as Rob points out, if($obj) and if(!$obj) are handled by different opcodes and these two opcodes are inconsistent in whether they call an object's cast_ob

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

One more thing, don't take this as thread safety isn't important. The better we can make PHP's thread-safety the better. But I won't run it on my Apache :) 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:

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

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 wr

Re: [PHP-DEV] Unicode-compatible extensions

Problem is that some extensions that don't "support" Unicode will still work. Extensions like gd might "almost" work out of the box. At 08:36 AM 8/24/2005, John Coggeshall wrote: On Wed, 2005-08-24 at 18:30 +0300, Stanislav Malyshev wrote: > JC>>> Maybe we can give extensions a way to indicate

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

At 08:05 AM 8/24/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: > Why? A great deal of users will be running with unicode semantics > turned off, and I don't see a good reason to break source compatibility > for them. For example, if Foo Inc. wrote a module for PHP 4, and they > want to migrat

Re: [PHP-DEV] Re: PHP Unicode support design document

Hi, On Aug 23, 2005, at 7:30 PM, Makoto Tozawa wrote: "HTTP Input Encoding ... If the HTTP request contains the encoding specification in the headers, then it will be used instead of this setting." With my best knowledge there isn't such http request header which specifies the encoding of the

Re: [PHP-DEV] Re: PHP 6.0 Wishlist

Michael, To your question, I don't want to encourage this style of programming. Andi At 10:24 PM 8/23/2005, Michael Walter wrote: Zeev, On 8/24/05, Michael Walter <[EMAIL PROTECTED]> wrote: > On 8/23/05, Zeev Suraski <[EMAIL PROTECTED]> wrote: > > >"Real" anonymous functions (as in, closures)

Re: [PHP-DEV] PHP 6.0 Wishlist

Well $proxy would automagically support the interfaces of the aggregated objects. And if there's a method you want to proxy to one rather the other you could fine tune that. Anything more than that would be getting into an OOP pissing contest which I don't feel like getting into, as it would be

Re: [PHP-DEV] PHP 6.0 Wishlist

Hello Andi, hu? Here's you example again: aggregate($obj2); /* Also aggregates interfaces */ $proxy->aggregate($obj3); $proxy->delegate($obj3, "method_that_exists_in_both_objects"); ?> ok lets change this to an interface like in my example: So what do you want to do about the fact that my d

Re: [PHP-DEV] PHP 6.0 Wishlist

Not if it's done they way I think it can be done... At 03:17 PM 8/24/2005, Marcus Boerger wrote: Hello Andi, you mean fine tune the 'protocol' to use the correct wording. It simply is incompatible with the interface concept. Wednesday, August 24, 2005, 11:48:33 PM, you wrote: > I don't mi

Re: [PHP-DEV] PHP 6.0 Wishlist

Hello Andi, you mean fine tune the 'protocol' to use the correct wording. It simply is incompatible with the interface concept. Wednesday, August 24, 2005, 11:48:33 PM, you wrote: > I don't mind not adding it, as long as we don't add "delegate" :) > Anyway, it's different from MI because it

Re: [PHP-DEV] Schroedinger Objects

> if(!$obj) results in a which calls convert_to_boolean() which in turn > calls convert_object_to_type() which has: I meant results in a ZEND_BOOL_NOT_SPEC_CV_HANDLER... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 6.0 Wishlist

I don't mind not adding it, as long as we don't add "delegate" :) Anyway, it's different from MI because it allows you to fine tune the interface... Andi At 12:01 PM 8/24/2005, Marcus Boerger wrote: Hello Andi, i said 'we could probably add'. But even though proxy/aggregation idea like you

[PHP-DEV] Schroedinger Objects

As per bug #34199 and as Rob points out, if($obj) and if(!$obj) are handled by different opcodes and these two opcodes are inconsistent in whether they call an object's cast_object handler. if($obj) results in a ZEND_JMPZ_SPEC_CV_HANDLER which calls i_zend_is_true() which always return true for ob

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

Hello Zeev, Wednesday, August 24, 2005, 4:41:25 PM, you wrote: > At 17:37 24/08/2005, Rasmus Lerdorf wrote: >>Steph wrote: >> > Hi Rasmus, >> > >> > >> >>Steph wrote: >> >> >> >>>If there's the capability to run PHP 6 without Unicode support, surely >> >>>there's no reason for extensions to lose

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

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 a

Re: [PHP-DEV] Poll result about PHP 6 Wish list

Hello Cyril, interesting - thanks! Wednesday, August 24, 2005, 2:11:14 PM, you wrote: > Dear internals readers, > I guess it's right that all of us are quite PHP geek and so i made a > pool on a popular french website (http://www.phpfrance.com). > I didn't say any word about the wishlist's wr

Re: [PHP-DEV] PHP 6.0 Wishlist

Hello Andi, i said 'we could probably add'. But even though proxy/aggregation idea like you offered and which i of course could implement in spl exists i still see no reason for it. The problem with the latter is that it only gives you back the original MI problems and doesn't work together with

[PHP-DEV] Nevermind

Ignore that last e-mail, helps if you call the function :) John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Can someone tell me ...

Why this crashes: php -r 'class a { function b() { return $this->b(); }} $c = new a(); $c- >b();' and this does not? php -r 'function a() { return a(); }' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.0.5 RC2

It's already been bumped. -Andrei On Aug 24, 2005, at 1:39 AM, Sebastian Bergmann wrote: Zeev Suraski schrieb: Any outstanding things for this release beyond PEAR and XMLRPC? I'd like to roll RC2 as soon as possible. libpcre needs to be bumped. -- Sebastian Bergmann

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

At 18:05 24/08/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: > Why? A great deal of users will be running with unicode semantics > turned off, and I don't see a good reason to break source compatibility > for them. For example, if Foo Inc. wrote a module for PHP 4, and they > want to migrate

Re: [PHP-DEV] Thread Safety Flag (was Re: [PHP-DEV] Unicode-compatible extensions)

John Coggeshall wrote: > On Wed, 2005-08-24 at 18:47 +0300, Stanislav Malyshev wrote: > >>Ah, now I see, so you propose along with "compiled in TS" to have >>"actually works in TS" flag. Only problem here is that extension author >>may probably not know if it works in TS - TS support is much mor

[PHP-DEV] Thread Safety Flag (was Re: [PHP-DEV] Unicode-compatible extensions)

On Wed, 2005-08-24 at 18:47 +0300, Stanislav Malyshev wrote: > Ah, now I see, so you propose along with "compiled in TS" to have > "actually works in TS" flag. Only problem here is that extension author > may probably not know if it works in TS - TS support is much more > complicated than unicod

Re: [PHP-DEV] Unicode-compatible extensions

JC>>That's basically what I'm saying, I guess maybe this is a PHP 6.0 JC>>wishlist sort of thing -- I'd like to see PHP when operating in thread JC>>safety mode be very unhappy loading extensions not flagged thread JC>>safe. Ah, now I see, so you propose along with "compiled in TS" to have "ac

Re: [PHP-DEV] Unicode-compatible extensions

On Wed, 2005-08-24 at 18:30 +0300, Stanislav Malyshev wrote: > JC>>> Maybe we can give extensions a way to indicate that they're Unicode > JC>>> compatible, and assume they're not if they don't. Non-compatible > JC>>> extensions will not be loaded and produce an error. > JC>> > JC>>Not to hijack

Re: [PHP-DEV] Unicode-compatible extensions

JC>>> Maybe we can give extensions a way to indicate that they're Unicode JC>>> compatible, and assume they're not if they don't. Non-compatible JC>>> extensions will not be loaded and produce an error. JC>> JC>>Not to hijack the topic, but if we are going to do something like this JC>>why not a

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

Steph wrote: >>What happens when the extension gets an IS_UNICODE string passed to it >>if they are not using zend_parse_parameters()? These strings can exist >>independent of the unicode semantics switch. > > > Just to be a pain - does anyone actually know off-hand of extensions that > _don't_

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

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

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

Steph wrote: >>What happens when the extension gets an IS_UNICODE string passed to it >>if they are not using zend_parse_parameters()? These strings can exist >>independent of the unicode semantics switch. > > > Just to be a pain - does anyone actually know off-hand of extensions that > _don't_

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

> What happens when the extension gets an IS_UNICODE string passed to it > if they are not using zend_parse_parameters()? These strings can exist > independent of the unicode semantics switch. Just to be a pain - does anyone actually know off-hand of extensions that _don't_ use zend_parse_paramet

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

Zeev Suraski wrote: > Why? A great deal of users will be running with unicode semantics > turned off, and I don't see a good reason to break source compatibility > for them. For example, if Foo Inc. wrote a module for PHP 4, and they > want to migrate to PHP 6 - it should be a simple recompile.

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

At 17:46 24/08/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: > At 17:37 24/08/2005, Rasmus Lerdorf wrote: > >> Steph wrote: >> > Hi Rasmus, >> > >> > >> >>Steph wrote: >> >> >> >>>If there's the capability to run PHP 6 without Unicode support, surely >> >>>there's no reason for extensions to lo

Re: [PHP-DEV] type hinting throwing a fatal error

On Wed, 24 Aug 2005, Zeev Suraski wrote: > At 17:21 24/08/2005, Rasmus Lerdorf wrote: > >Steph wrote: > > > If there's the capability to run PHP 6 without Unicode support, surely > > > there's no reason for extensions to lose back compatability when they're > > > updated...? > > > >That's going to

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

Zeev Suraski wrote: > At 17:37 24/08/2005, Rasmus Lerdorf wrote: > >> Steph wrote: >> > Hi Rasmus, >> > >> > >> >>Steph wrote: >> >> >> >>>If there's the capability to run PHP 6 without Unicode support, surely >> >>>there's no reason for extensions to lose back compatability when >> they're >> >>>

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

At 17:37 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: > Hi Rasmus, > > >>Steph wrote: >> >>>If there's the capability to run PHP 6 without Unicode support, surely >>>there's no reason for extensions to lose back compatability when they're >>>updated...? >> >>That's going to be tough. They will

Re: [PHP-DEV] type hinting throwing a fatal error

> > Ouf - you're effectively saying that Unicode support will need to be enabled > > via INI directives on a per-extension basis? Or that there will need to be > > two versions of every PHP extension? > > Not at all. But it would be nice if the extension did something > intelligent when passed an

Re: [PHP-DEV] type hinting throwing a fatal error

Steph wrote: > Hi Rasmus, > > >>Steph wrote: >> >>>If there's the capability to run PHP 6 without Unicode support, surely >>>there's no reason for extensions to lose back compatability when they're >>>updated...? >> >>That's going to be tough. They will definitely lose binary >>compatibility bec

Re: [PHP-DEV] type hinting throwing a fatal error

Hi Rasmus, > Steph wrote: > > If there's the capability to run PHP 6 without Unicode support, surely > > there's no reason for extensions to lose back compatability when they're > > updated...? > > That's going to be tough. They will definitely lose binary > compatibility because all sorts of int

[PHP-DEV] Re: 5.0.5 RC2

Zeev Suraski wrote: > Any outstanding things for this release beyond PEAR and XMLRPC? I'd > like to roll RC2 as soon as possible. PEAR is not an issue (that's what my message about finishing sync was all about) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] type hinting throwing a fatal error

At 17:21 24/08/2005, Rasmus Lerdorf wrote: Steph wrote: > If there's the capability to run PHP 6 without Unicode support, surely > there's no reason for extensions to lose back compatability when they're > updated...? That's going to be tough. They will definitely lose binary compatibility beca

Re: [PHP-DEV] type hinting throwing a fatal error

Steph wrote: > If there's the capability to run PHP 6 without Unicode support, surely > there's no reason for extensions to lose back compatability when they're > updated...? That's going to be tough. They will definitely lose binary compatibility because all sorts of internal structures are chan

Re: [PHP-DEV] type hinting throwing a fatal error

> > Replacing the meaning of E_ERROR is elegant, but it does create a > > problem of cross-version compatibility of extensions (at the source > > code level). If you want to raise an error that terminates execution, > > you'll have to do it in two different ways - that's quite annoying. > > While

Re: [PHP-DEV] Poll result about PHP 6 Wish list

CPdG>>> 7. Make identifiers case-sensitive I think it's not that good idea - real lot of code would stop working. CPdG>>> 8. Remove various function aliases What for, I wonder? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PH

[PHP-DEV] Poll result about PHP 6 Wish list

Dear internals readers, I guess it's right that all of us are quite PHP geek and so i made a pool on a popular french website (http://www.phpfrance.com). I didn't say any word about the wishlist's writer because of Rasmus's charism could have oriented the answer in his direction. I just wrote the

RE: [PHP-DEV] Returning References from Internal Functions

Thank you Sara. Now the bug is fixed in PHP_5_1 and HEAD. The test is in attachment. Dmitry. > -Original Message- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 4:47 AM > To: internals@lists.php.net > Cc: Andi Gutmans > Subject: Re: [PHP-DEV] Returning

RE: [PHP-DEV] 5.0.5 RC2

Uh-huh, mister know-it-all... the only problem is that 5.1 isn't out yet. So why don't you just put a sock in it and help pushing 5.1 instead? - David > -Original Message- > From: Jani Taskinen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 12:27 PM > To: Zeev Suraski > Cc:

Re: [PHP-DEV] 5.0.5 RC2

Yeah, don't release it and push 5.1 instead. Nobody should be using 5.0 anymore after 5.1 is out.. --Jani On Wed, 24 Aug 2005, Zeev Suraski wrote: Any outstanding things for this release beyond PEAR and XMLRPC? I'd like to roll RC2 as soon as possible. Thanks, Zeev -- PHP

RE: [PHP-DEV] 5.0.5 RC2

Yeah, http://www.securitytracker.com/alerts/2005/Aug/1014744.html - David > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann > Sent: Wednesday, August 24, 2005 10:40 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] 5.0.5 RC2 > > Zeev Sur

Re: [PHP-DEV] 5.0.5 RC2

Zeev Suraski schrieb: > Any outstanding things for this release beyond PEAR and XMLRPC? I'd > like to roll RC2 as soon as possible. libpcre needs to be bumped. -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 686

RE: [PHP-DEV] 5.0.5 RC2

Hi, Zeev Suraski wrote on Wednesday, August 24, 2005 9:50 AM: > Any outstanding things for this release beyond PEAR and XMLRPC? I'd > like to roll RC2 as soon as possible. Some hint: Some applications get broken after upgrade from PHP 5.0.4 to 5.0.5RC1. For example t

Re: [PHP-DEV] type hinting throwing a fatal error

On Wed, 24 Aug 2005, Zeev Suraski wrote: > At 09:26 24/08/2005, Derick Rethans wrote: > >On Tue, 23 Aug 2005, Andi Gutmans wrote: > > > > > I didn't quite understand. Users would be able to handle E_FATAL > > > errors? How would exceptions from those user handlers propagate > > > the C extension

[PHP-DEV] 5.0.5 RC2

Any outstanding things for this release beyond PEAR and XMLRPC? I'd like to roll RC2 as soon as possible. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] type hinting throwing a fatal error

At 09:26 24/08/2005, Derick Rethans wrote: On Tue, 23 Aug 2005, Andi Gutmans wrote: > I didn't quite understand. Users would be able to handle E_FATAL errors? How > would exceptions from those user handlers propagate the C extensions? No, they would only be able to catch E_ERROR, E_FATAL is t