RE: [PHP-DEV] 5.0.5 RC2

Hi Zeev, Zeev Suraski wrote on Thursday, August 25, 2005 7:37 PM: >> Fatal error: Only variables can be passed by reference in >> /xxx/www/wiki/includes/SpecialSpecialpages.php on line 68<: >> aeaeciaobsoee > > It appears to be due to a genuine fix for bug #3

Re: [PHP-DEV] XML URIs and streams

Thanks for the reminder Steph. Had slipped my mind. finally commited. Rob Steph wrote: Rob, hi, You never committed this (or anything else in ext/libxml since then as far as I can see) - do you still intend to? - Steph-working-on-backlog-and-will-shoot-the-next-person-to-ask -- PHP Inte

Re: [PHP-DEV] Property Overloading RFC

At 06:00 AM 8/25/2005, Edin Kadribasic wrote: Derick Rethans wrote: > And how can you possibly argue that this more complex than all the other > OO crap that people are suggesting here I belive that we should do our best to filter out this storm of OO feature requests. People want to make PH

Re: [PHP-DEV] Re: PHP Unicode support design document-keeping existing functionality

> If we don't make the functions provide reasonable behavior for unicode, then every program needs to be rewritten to change function names. I agree. I asked it because the Backwards Compatibility section states the following: "... the upgrade to Unicode-enabled PHP has to be transparent. Thi

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

In some environments you *need* to run a zts enabled PHP. People that run in those environments can heed the warnings about potential stability issues, evaluate them, and decide whether it makes sense for their application. I don't see any compelling need to rip out a feature that is essential for

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

Tex Texin wrote: I wrote a little test php program that has 2 identical forms. You enter text in either form and it posts and displays the hex codes for the bytes. The first form does not set accept-charset, so it defaults to utf-8. The second form overrides the page encoding and sets accept-cha

RE: [PHP-DEV] Re: PHP Unicode support design document- encoding negotiation

see the section on negotiation in this as well: http://www.xencraft.com/training/webstandards.html Tex Texin Internationalization Architect, Yahoo! Inc. > -Original Message- > From: Adam Maccabee Trachtenberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 25, 2005 8:06 AM > T

Re: [PHP-DEV] 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 a

Re: [PHP-DEV] Schroedinger Objects

Yep, the default for an instantiated object should be true (i.e. it's not null). Andi At 12:14 AM 8/25/2005, Marcus Boerger wrote: Hello Andi, in that case we are providing a default conversion, maybe like the old one? Or just always return 1 like we do in 5.0 ? marcus Thursday, August 25

Re: [PHP-DEV] Property Overloading RFC

Hello David, if we stay with abstract then it doesn't (actually it was a proposal from me from 13 month ago not open discussed). The other point you said it would make it non virtual by declaring it, that's plain wrong. Even after declaring you'd be able to do lazy initialization. And that's the

RE: [PHP-DEV] Property Overloading RFC

I have to say I still don't get the point of this. If you're declaring virtual properties, you can just use normal declare normal, non-virtual variables just as well. It's pointless if you ask me. They're not virtual anymore if you're declaring them beforehand. _This_ would be something that adds _

Re: [PHP-DEV] Re: Just some feedback on MI

Guys, We're wasting bandwidth here and it's really hard to stay focused on real issues. We took the decision a while ago to go with interfaces and not do MI (rightly so). I suggest that the newcomers to the list (Lukas not you), who are advocating for it, go and read the archives. It's not wo

Re: [PHP-DEV] Property Overloading RFC

Hello Derick, Thursday, August 25, 2005, 2:01:56 PM, you wrote: > On Tue, 2 Aug 2005, Derick Rethans wrote: >> we're finding some problems with property overloading (__get() and >> __set()). Here is an RFC describing what we'd like to see changed. >> Please comment on this. > I updated the pr

[PHP-DEV] Re: Just some feedback on MI

Oliver Grätz wrote: This is a valid argument. PHP has always been the BORG language that assimilates every positive aspect of other languages. Nowadays PHP users can use complex class hierarchies, interfaces, expections ans a lot more. But they may still use simple functions and use "global" for

Re: [PHP-DEV] Property Overloading RFC

Derick Rethans wrote: On Tue, 2 Aug 2005, Derick Rethans wrote: I updated the proposal: http://files.derickrethans.nl/property_overloading.html 1) seems to be an issue in doxygen and phpDocumentor 2) this seems solveable with a non public set of arrays containing information about the prop

Re: [PHP-DEV] Just some feedback on MI

Hello Oliver, the short answer is we don't want virtual inheritance. marcus Thursday, August 25, 2005, 10:30:34 PM, you wrote: > Hello gods of PHP development ;-) > I'm just a PHP-programmer, but I've been reading the PHP6 discussions > here for a while, especially the talk about MI vs inter

Re: [PHP-DEV] Just some feedback on MI

Good feedback :) delegates + MI -- Joseph Crawford Jr. Codebowl Solutions, Inc. 1-802-671-2021 [EMAIL PROTECTED]

[PHP-DEV] Just some feedback on MI

Hello gods of PHP development ;-) I'm just a PHP-programmer, but I've been reading the PHP6 discussions here for a while, especially the talk about MI vs interfaces. I've been all for MI up to the moment where Marcus Boerger came up with this: > class Document implements Printable { > delegate

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

On Thu, 2005-08-25 at 23:09 +0300, Zeev Suraski wrote: > There are almost no advantages to multithreaded PHP. There are > disadvantages (the reduced stability is inherent; no matter how good PHP > gets, multi-process deployments are by definition more > robust). Performance is slightly degra

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

I don't think anyone was arguing that we should fix TS issues. We've been doing that for ages (since the early days of PHP 4). The question is wether there is much value in marking extensions as thread-safe. At 12:35 PM 8/25/2005, John Coggeshall wrote: I don't buy into the argument that we sh

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

I generally disagree. There are almost no advantages to multithreaded PHP. There are disadvantages (the reduced stability is inherent; no matter how good PHP gets, multi-process deployments are by definition more robust). Performance is slightly degraded too, so why bother? And yes, unlik

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

I don't buy into the argument that we shouldn't start even trying to solve the thread safety issues in PHP because of some arbitrary "we can't tell" or "it's faster not to do it" sort of argument. Threads aren't exactly an archaic or edge technology, and it's just stubborn of us not to support them

Re: [PHP-DEV] Re: 'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV]PHP 6.0 Wishlist

Hello Christian, Thursday, August 25, 2005, 12:17:25 PM, you wrote: > Jochem Maas wrote: >> I would see this as a optional addition to the syntax of interfaces... >> i.e. everything works as before but you can add default function bodies >> which would behave as if it was defined in each class th

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

tch is here: >> > >> > http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt >> > >> > Any comments? >> >>+1 overall. As much as I like to keep name short, I think the full >>E_RECOVERABLE_ERROR maybe better in this case, just be 100% clear it is >&

Re: [PHP-DEV] Property Overloading RFC

Hello Derick, Thursday, August 25, 2005, 2:01:56 PM, you wrote: > On Tue, 2 Aug 2005, Derick Rethans wrote: >> we're finding some problems with property overloading (__get() and >> __set()). Here is an RFC describing what we'd like to see changed. >> Please comment on this. > I updated the pr

Re: [PHP-DEV] XML URIs and streams

Rob, hi, You never committed this (or anything else in ext/libxml since then as far as I can see) - do you still intend to? - Steph-working-on-backlog-and-will-shoot-the-next-person-to-ask - Original Message - From: "Rob Richards" <[EMAIL PROTECTED]> To: Sent: Sunday, August 07, 2005 4

RE: [PHP-DEV] 5.0.5 RC2

At 11:33 24/08/2005, =?us-ascii?Q?Sonke_Ruempler?= wrote: 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 bro

Re: [PHP-DEV] Property Overloading RFC

On Aug 25, 2005, at 8:01 AM, Derick Rethans wrote: On Tue, 2 Aug 2005, Derick Rethans wrote: I updated the proposal: http://files.derickrethans.nl/property_overloading.html #1) It seems to me that after declaring the property with the property keyword, the property isn't so virtual anymor

Re: [PHP-DEV] PHP Unicode strings impl proposal

On Aug 23, 2005, at 11:31 PM, Rolland Santimano wrote: I meant that 'start'/'length' would be UChar counts and probably fall in the middle of a lead/trail sequence. But as you mentioned below, the iteration macros should take care of that. start/length parameters should always be interpreted i

[PHP-DEV] Re: PHP 6.0 Wishlist

OF>>don't want to be boring but php have serious problems like OF>>no-namespaces. It gives headaches to any C programmer. It is PHP Because PHP is not C, neither it is Java, Perl, Python, C++, ML, Smalltalk, Lisp, Javascript, Z80 assembler or any other language one was trained into. So to expect

[PHP-DEV] Re: PHP 6.0 Wishlist

I am PHP programmer since a time and I wish php to be more closed to a serious language. I am annoyed by a lot of things in PHP. For example in the following code: I ask you why $thestring is available outside of the while loop. I don't want to be boring but php have serious problems like no-nam

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

Ilia Alshanetsky wrote: > I think there is a good reason for this patch making its way into PHP > 5.1 and 5.0, any chance relevant RMs could be convinced to allow it? :-) Not sure about 5.0, but it should go into (yet unreleased) 5.1 IMHO. Edin -- PHP Internals - PHP Runtime Development Mailing

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

On Wed, 24 Aug 2005, Andrei Zmievski wrote: > I took a closer look at this today and RFC 2616 does not specify > whether user agents are supposed to send a charset parameter in the > Content-Type header of the POST request. I did not see any of my > browsers doing so. I think we can safely disrega

[PHP-DEV] Calling method on non-object recoverable? (was: type hinting throwing a fatal error)

Derick Rethans wrote: > I implemented that (except I dropped the _ERROR part for > E_RECOVERABLE_ERROR as I found it too long). The patch is here: > > http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt > > Any comments? Since this new error level is being created, I

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

Hi, > 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(); }' because you forgot to call a(); This also crashes: php -r "function a() { return a(); } a();" Sven -- PHP Internals -

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

I think there is a good reason for this patch making its way into PHP 5.1 and 5.0, any chance relevant RMs could be convinced to allow it? :-) Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Property Overloading RFC

Derick Rethans wrote: If you would have properly read the proposal you see that there are 3! problems with it. And instead of whining about things, I actually spend > some time of contributing with patches too. Let's agree to disagree. I easily work around these 3 "problems" here, so my patch

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

E_ERROR as I found it too long). The patch is here: > > > > > > > > http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt > > > > > > > > Any comments? > > > > > >+1 overall. As much as I like to keep name short, I thi

Re: [PHP-DEV] Property Overloading RFC

On Thu, 25 Aug 2005, Edin Kadribasic wrote: > Derick Rethans wrote: > > And how can you possibly argue that this more complex than all the other > > OO crap that people are suggesting here > > I belive that we should do our best to filter out this storm of OO > feature requests. People want

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

t; > http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt > > > > > > Any comments? > > > >+1 overall. As much as I like to keep name short, I think the full > >E_RECOVERABLE_ERROR maybe better in this case, just be 100% clear it is > >an error

Re: [PHP-DEV] Property Overloading RFC

On Thu, 25 Aug 2005, Stanislav Malyshev wrote: > DR>>If nobody as any better idea on how to solve it I'd like to start > DR>>implementing it. > > Some questions about the RFC: > > 1. What exactly property public $x = 1; means? I.e., first of all, what > "1" means - does it mean that __get guar

Re: [PHP-DEV] Property Overloading RFC

Derick Rethans wrote: > And how can you possibly argue that this more complex than all the other > OO crap that people are suggesting here I belive that we should do our best to filter out this storm of OO feature requests. People want to make PHP look like some other OO languages for no good

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

At 15:44 25/08/2005, Ilia Alshanetsky wrote: Derick Rethans wrote: > I implemented that (except I dropped the _ERROR part for > E_RECOVERABLE_ERROR as I found it too long). The patch is here: > > http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt > > Any comment

Re: [PHP-DEV] Property Overloading RFC

On Thu, 25 Aug 2005, Christian Schneider wrote: > Derick Rethans wrote: > > I updated the proposal: > > http://files.derickrethans.nl/property_overloading.html > > > > If nobody as any better idea on how to solve it I'd like to start > > implementing it. > > I seem to remember that we had some v

Re: [PHP-DEV] Property Overloading RFC

Christian Schneider wrote: > Derick Rethans wrote: > >> I updated the proposal: >> http://files.derickrethans.nl/property_overloading.html >> >> If nobody as any better idea on how to solve it I'd like to start >> implementing it. > > > I seem to remember that we had some voices here stating tha

Re: [PHP-DEV] Property Overloading RFC

DR>>If nobody as any better idea on how to solve it I'd like to start DR>>implementing it. Some questions about the RFC: 1. What exactly property public $x = 1; means? I.e., first of all, what "1" means - does it mean that __get guarantees to return 1 on __get("x") if it was never set? Should

Re: [PHP-DEV] Property Overloading RFC

Derick Rethans wrote: I updated the proposal: http://files.derickrethans.nl/property_overloading.html If nobody as any better idea on how to solve it I'd like to start implementing it. I seem to remember that we had some voices here stating that the current mechanisms are sufficient. Adding

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

Derick Rethans wrote: > I implemented that (except I dropped the _ERROR part for > E_RECOVERABLE_ERROR as I found it too long). The patch is here: > > http://files.derickrethans.nl/patches/e_fatal-20050825.diff.txt > > Any comments? +1 overall. As much as I like to keep name

[PHP-DEV] Re: 'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV] PHP 6.0 Wishlist

Zeev Suraski wrote: How is that different from multiple inheritance? I guess the only difference is that interfaces don't strictly fall into a hierarchy? also interfaces don't implement properties or class constants which would simplify matters? anyway I guess I have to read more on the subjec

Re: [PHP-DEV] Re: 'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV]PHP 6.0 Wishlist

Christian Schneider wrote: Jochem Maas wrote: I would see this as a optional addition to the syntax of interfaces... i.e. everything works as before but you can add default function bodies which would behave as if it was defined in each class that implements the given interface. if this is a t

Re: [PHP-DEV] Property Overloading RFC

On 8/25/05, Derick Rethans <[EMAIL PROTECTED]> wrote: > On Tue, 2 Aug 2005, Derick Rethans wrote: > > > we're finding some problems with property overloading (__get() and > > __set()). Here is an RFC describing what we'd like to see changed. > > Please comment on this. > > I updated the proposal:

Re: [PHP-DEV] Property Overloading RFC

On Tue, 2 Aug 2005, Derick Rethans wrote: > we're finding some problems with property overloading (__get() and > __set()). Here is an RFC describing what we'd like to see changed. > Please comment on this. I updated the proposal: http://files.derickrethans.nl/property_overloading.html If nobod

Re: [PHP-DEV] Re: Real properties in PHP

On Thu, 25 Aug 2005, Christian Schneider wrote: > This can be easily done with > > function __get($name) > { > $get = "get_$name"; > > return $this->$get(); > } > > function __set($name, $value) > { > $set = "set_$name"; > > $this->$set($value); > } > > in your

[PHP-DEV] Re: Real properties in PHP

On 8/25/05, Christian Schneider <[EMAIL PROTECTED]> wrote: > Marian Kostadinov wrote: > > public getter fullName { // may also have () > >return "{$this->firstName} {$this->lastName}"; > > } > > > > public setter fullName ($value) { // may also not have ($value) but > > a special var. > >

[PHP-DEV] Re: Real properties in PHP

Marian Kostadinov wrote: public getter fullName { // may also have () return "{$this->firstName} {$this->lastName}"; } public setter fullName ($value) { // may also not have ($value) but a special var. list ($this->firstName, $this->lastName) = explode (' ', $value, 2); } This ca

[PHP-DEV] Real properties in PHP

I wrote about real properies a few days ago but no one seems to be interested in it. I think that it would be nice to have real properties present in PHP. I mean properties like those in C# but a little more flexible by allowing getter and setter to have different visibility. See sample code below

[PHP-DEV] Re: 'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV] PHP 6.0 Wishlist

How is that different from multiple inheritance? Zeev At 12:44 25/08/2005, Jochem Maas wrote: in a totally non-academic and impure way I have always thought that it would be nice to be able to define function bodies in interface declarations -- PHP Internals - PHP Runtime Development Mailing

[PHP-DEV] Re: 'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV]PHP 6.0 Wishlist

Jochem Maas wrote: I would see this as a optional addition to the syntax of interfaces... i.e. everything works as before but you can add default function bodies which would behave as if it was defined in each class that implements the given interface. if this is a truely evil concept I would ve

[PHP-DEV] 'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV] PHP 6.0 Wishlist

Andi Gutmans wrote: 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

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

At 10:17 25/08/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? Whenever we touch a shared reso

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

introduction of a new error level, > E_RECOVERABLE_ERROR, and keep E_ERROR with its existing meaning. I implemented that (except I dropped the _ERROR part for E_RECOVERABLE_ERROR as I found it too long). The patch is here: http://files.derickrethans.nl/patches/e_fatal-20050825.diff.tx

Re: [PHP-DEV] PHP 6.0 Wishlist

JM>>I think I remember reading that PHP always evaluates expressions from right JM>>to left, so I guess there may be a considerable codebase change required. I personally don't see a point in "considerable codebase change" just for the sake of syntactic prettyness. It doesn't add anything to the

Re: [PHP-DEV] Unicode-compatible extensions

AG>>Problem is that some extensions that don't "support" Unicode will AG>>still work. Extensions like gd might "almost" work out of the box. We can go over "standard" extensions and rubber-stamp ones that we think do not need changes. As for PECL/external extensions, I think maintainers should

RE: [PHP-DEV] Re: PHP Unicode support design document-keeping existing functionality

1) sorry I am compelled to change the subject so all threads don’t look the same. 2) It's a no-win situation. If we don't make the functions provide reasonable behavior for unicode, then every program needs to be rewritten to change function names. The number of places where hard coded constant

RE: [PHP-DEV] PHP 6.0 Wishlist

if (2 < $x <= 4) {} Doesn't this collide with its current meaning: if ( (2 < $x) <= 4) {} i.e. parsing left to right, the true/false result of 2 < $x, is compared with <= 4. Changing the meaning could break some programs. Tex Texin Internationalization Architect, Yahoo! Inc. > -

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

With respect to the encoding of a form, several concepts are being mixed together. Here is my brief take on it. First, if nothing else is done, the form will be in the encoding of the containing web page. It is true that the http request to the server will not contain a content-type charset identi

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

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: > Mar

Re: [PHP-DEV] Schroedinger Objects

Hello Andi, in that case we are providing a default conversion, maybe like the old one? Or just always return 1 like we do in 5.0 ? marcus Thursday, August 25, 2005, 1:31:08 AM, you wrote: > Yep I think that's a good point. > Checking for cast is the right thing IMO. > At 02:45 PM 8/24/2005,