Re: [PHP-DEV] New win32 build system
Andi Gutmans wrote: Is win32build.zip updated with all of the latest and greatest including libXML2? No, it isn't. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
At 09:30 AM 12/3/2003 +0100, Sebastian Bergmann wrote: Andi Gutmans wrote: Is win32build.zip updated with all of the latest and greatest including libXML2? No, it isn't. Any chance of updating it or making an additional package for ppl who have a DSL line :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Andi Gutmans wrote: Any chance of updating it or making an additional package for ppl who have a DSL line :) I only have a hacked build of libxml2/libxslt here that someone from IRC (can't remember who) sent me a while ago. Anyhow, I think it would be best to maintain the Win32 build dependencies in a new CVS module allow for - Incremental updates - Automatically up2date-ness - A cronjob that creates the archive we now offer -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). I think it is not a good idea to separate PHP from the rest of the world like this. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: admin [mailto:admin] On Behalf Of Sebastian Bergmann Sent: Wednesday, December 03, 2003 10:36 AM Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). I think it is not a good idea to separate PHP from the rest of the world like this. Ok so it seems that the CS was just reverted (apparently Derick actually intended to have reverted the CS much earlier). I guess we have the its ugly and its harder to read on one side. And the it's the OO standard, it is easier to read for OO code and it breaks compatibility with PEAR on the other side. Since Marcus patch there are no technical reasons anymore (since we can now preserve case in error messages etc). However I think everybody on the suckyCaps side needs to ask themselves if they don't happen to be against this because they think OO sucks. And if that is the case maybe they shouldn't tell the people that do intent to use the OO API's that they should look like the good ol functional APIs. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003, Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). It was not agreed on that this is a REQUIREMENT for all code, that's why I removed it. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CODING_STANDARDS
On Wednesday, Dec 3, 2003, at 10:12 Europe/Copenhagen, Derick Rethans wrote: derick Wed Dec 3 04:12:39 2003 EDT Modified files: /php-srcCODING_STANDARDS Log: - I am sure I reverted this before No you didn't. Care to elaborate on this change? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003 10:42:33 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 3 Dec 2003, Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). It was not agreed on that this is a REQUIREMENT for all code, that's why I removed it. Not to raise the flame again, but I think you are wrong here. See http://pear.php.net/news/meeting-2003-summary.php. Especially this line: PHP object-oriented APIs should follow the PEAR coding standards. on which we agreed even before the meeting. Method names following PEAR CS must use studlyCaps: http://pear.php.net/manual/en/standards.naming.php Meeting where you, Sebastian Bergmann, Hartmut Holzgraefe, Jeroen Houben, Wolfram Kriesing, Jan Lehnardt, George Schlossnagle, Lukas Smith, Markus Wolff and Jani were present (add those I forgot ;) ), and all people online via IRC. And now I'm wondering why that suddenly becomes ugly and, as pointed Sebastion, why PHP should follow different things than 99.% of others OO langages. pierre reading 10k pending mails ... :P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: Meeting where you, Sebastian Bergmann, Hartmut Holzgraefe, Jeroen Houben, Wolfram Kriesing, Jan Lehnardt, George Schlossnagle, Lukas Smith, Markus Wolff and Jani were present (add those I forgot ;) ), and all people online via IRC. I was not at this meeting. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 3 Dec 2003, Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). It was not agreed on that this is a REQUIREMENT for all code, that's why I removed it. As far as I'm concerned, no such agreement that it is a requirement was made so far on this list... (correct me if I'm wrong) Just leaving it as a sort of recommendation would be enough. Personally I don't think it should be the standard, though I prefer studlyCaps even with PHP. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 03 Dec 2003 19:13:13 +0900 Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 3 Dec 2003, Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). It was not agreed on that this is a REQUIREMENT for all code, that's why I removed it. As far as I'm concerned, no such agreement that it is a requirement was made so far on this list... (correct me if I'm wrong) Well, no idea about when we should consider something agreed or not. However here is the archives: http://marc.theaimsgroup.com/?l=php-devm=105715671709005w=2 http://marc.theaimsgroup.com/?l=php-devm=10527308470w=2 follow the threads to get (or not) the agreement ;) hth (to avoid flames ;) pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wednesday, Dec 3, 2003, at 11:13 Europe/Copenhagen, Moriyoshi Koizumi wrote: Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 3 Dec 2003, Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. Whether you like it or not, most people who use programming languages that support the paradigm of object-orientation use studlyCaps (or whatever you want to call them). It was not agreed on that this is a REQUIREMENT for all code, that's why I removed it. As far as I'm concerned, no such agreement that it is a requirement was made so far on this list... (correct me if I'm wrong) OK. Let's make such an agreement then. Just leaving it as a sort of recommendation would be enough. Personally I don't think it should be the standard, though I prefer studlyCaps even with PHP. I think this is the worst possible option. We shouldn't repeat the same mistake as with the function names which lead us down the path of inconsistency from which we cannot recover. Since most of the rest of the OO world (including PHP OO world) is using studlyCaps for method names, lets make that a standard for PHP OO APIs. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: See http://pear.php.net/news/meeting-2003-summary.php. Especially this line: PHP object-oriented APIs should follow the PEAR coding standards. i don't remember this and even if i did i don't think a PEAR project meeting is able to take any decision on how PHP core developement should be done (and vice versa) (to me it looks more like it happened the other way round with PEAR deciding in the distant past not to use the coding conventions that we finally came up with for PHP function names but to do it the very other way as we still have it with the gd and oci functions but do not want to see in any further extensions ...) Meeting where you, Sebastian Bergmann, Hartmut Holzgraefe, ... just for the records: some of us left early to catch our train ... And now I'm wondering why that suddenly becomes ugly IMHO it has been ugly ever since ... and, as pointed Sebastion, why PHP should follow different things than 99.% of others OO langages. OTOH: why should we? PS: can you prove that 99.% figure? i'd believe a value of maybe 80% but definetly not 99.% ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS (fwd)
Heavy -1 on making hardTooTypeAndEvenWorseToReadCaps a recommendation for the APIs exposed by PHP. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Hi As far as I'm concerned, no such agreement that it is a requirement was made so far on this list... (correct me if I'm wrong) Well, no idea about when we should consider something agreed or not. However here is the archives: http://marc.theaimsgroup.com/?l=php-devm=105715671709005w=2 http://marc.theaimsgroup.com/?l=php-devm=10527308470w=2 follow the threads to get (or not) the agreement ;) IIRC there was an agreement a few months ago to use studlyCaps after some lengthy thread.. pierre Welcome back Pierre =) /Magnus -- We prefer to speak evil of ourselves rather than not speak of ourselves at all. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Tue, 2003-12-02 at 12:51, Andi Gutmans wrote: At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote: For the next 18-24 months, we are going to have to deal with code running in both PHP 4 and 5. Why not declare var an alias for public, not throw E_STRICT for it and be done with it? If not this issue will be a real PITA for PEAR users. Stig, E_STRICT will be disabled by default. It is only meant for people who want to be sure that they are using the recommended methods, and that definitely includes not using var. People who don't feel like it don't need to use it. It'd be ridiculous to have two new pedantic modes just because of this. It's not as if there are so many things we can recommend on anyway. I guess the core of the problem here is if E_STRICT is included in E_ALL. PEAR developers are encouraged to write E_ALL safe code. Changing that to E_ALL ~E_STRICT doesn't work, because E_STRICT does not exist in PHP 4. The goal here is to assure smooth transition from PHP 4 to PHP 5 for PEAR users. To me that means not having to use version_compare() or have different versions of files for PHP 4 and 5. Solutions that would work for PEAR: * E_ALL not including E_STRICT * var equivalent to public (ie not throwing E_STRICT) - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Tue, 2003-12-02 at 18:43, Marcus Boerger wrote: Hello Christian, Tuesday, December 2, 2003, 1:14:12 PM, you wrote: Andi Gutmans wrote: E_STRICT will be disabled by default. It is only meant for people who want to be sure that they are using the recommended methods, and that definitely includes not using var. The problem is that it doesn't match the real world. People _are_ using PEAR and people _are_ using PHP4. So they simply _can't_ change var to public. So E_STRICT is currently way too noisy for them. Hence they'll not use it. That's why I think two levels (e.g. E_STRICT for backward compatible stuff and E_PEDANTIC for everything) makes sense. Or call it E_DEPRECATED and E_STRICT if you want. I for one would love to use E_DEPRECATED if it existed but I can't use E_NOTICE (I use uninitialized variables all the time, it's one of the main features of PHP for me) or E_STRICT (my code has to work on PHP4). I see all your concerns. But from my point of view pear has (of course) the problem that it is written in php4 and for php4. So PEAR needs to address the move towards php5 code anyway. An optional E_STRICT would help here wouldn't it? PEAR is addressing the move towards PHP 5, but why make it more difficult? We can handle issues at runtime, but during compilation there's not much we can do. What we're trying to avoid is to force every package maintainer to roll PHP 5 specific releases for packages that still support PHP 4. Smooth transition requires that one package at a time can be transitioned, or we would create a dependency mess out of this world. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Wed, 3 Dec 2003, Stig S. Bakken wrote: On Tue, 2003-12-02 at 12:51, Andi Gutmans wrote: At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote: For the next 18-24 months, we are going to have to deal with code running in both PHP 4 and 5. Why not declare var an alias for public, not throw E_STRICT for it and be done with it? If not this issue will be a real PITA for PEAR users. Stig, E_STRICT will be disabled by default. It is only meant for people who want to be sure that they are using the recommended methods, and that definitely includes not using var. People who don't feel like it don't need to use it. It'd be ridiculous to have two new pedantic modes just because of this. It's not as if there are so many things we can recommend on anyway. I guess the core of the problem here is if E_STRICT is included in E_ALL. PEAR developers are encouraged to write E_ALL safe code. Changing that to E_ALL ~E_STRICT doesn't work, because E_STRICT does not exist in PHP 4. That's already changed... E_ALL does not include E_STRICT anymore... Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Mon, 2003-12-01 at 21:47, Andi Gutmans wrote: At 03:32 PM 12/1/2003 -0500, Daniel Convissor wrote: On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote: I don't quite understand the problem. E_STRICT was only meant for people who really want to be pedantic. I think we can make it not part of E_ALL. Is that OK? Better. The only drawback is people who do want to be pedantic will get flooded by tons of warnings about var rather than being able to focus on real problems. Guess I'M being pedantic. :) If they'd like to keep var then they aren't pedantic :) I'm sure that even with big apps doing a search and replacing var with public will take no more than half an hour. It's not as simple as that. In addition to your own code, you install a bunch of packages, none of them maintained by yourself. Some of these packages you use directly from your own code, others are dependencies of those and so on. I would never put anything into production with a blind search/replace in code that I did not know well. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: And now I'm wondering why that suddenly becomes ugly and, as pointed Sebastion, why PHP should follow different things than 99.% of others OO langages. one reason might bee that we do not have case sensitive function names so that it is possible to use whatever CAPSulation you want as it already happens today with code using GD or OCI functions when reading code that uses e.g. GD you'll see - imagecreatefromgif - imageCreateFromGif - ImageCreateFromGif - ImageCreateFromGIF - ... and i see no reason why we should expect this *not* to happen with code using PEAR classes i know that it is to late to change the PEAR coding standards in that respect but i don't want to see this virus spread ... :-| -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 11:48 AM Pierre-Alain Joye wrote: And now I'm wondering why that suddenly becomes ugly and, as pointed Sebastion, why PHP should follow different things than 99.% of others OO langages. one reason might bee that we do not have case sensitive function names so that it is possible to use whatever CAPSulation you want as it already happens today with code using GD or OCI functions when reading code that uses e.g. GD you'll see - imagecreatefromgif - imageCreateFromGif - ImageCreateFromGif - ImageCreateFromGIF - ... and i see no reason why we should expect this *not* to happen with code using PEAR classes i know that it is to late to change the PEAR coding standards in that respect but i don't want to see this virus spread ... :-| Ok I can comment on how things are in PEAR 1) I have seen people complain about our CS .. but studyCaps has rarely been addressed 2) Right now error messages are not case preserving .. even still few people complained (actually I don't remember anyone) 3) I have seen code being posted on the web using PEAR and its all nicely along studyCaps So please realize that studlyCaps is how it is done in the OO world. Its how it is done in the PHP OO world (I don't have statistical data to back this up, but I feel quite safe with my argument here - I would appreciate it if someone would find a way to proof me wring/right). And yes I know that it is no major source of problems because I happen to be heavily involved in one of the largest PHP OO projects that exists. Aside from that yes it will be a major problem for PEAR if objects don't follow studyCaps as this means we will have to either kick our CS or wrap objects instead of just exending them. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS (fwd)
On Wednesday, Dec 3, 2003, at 11:33 Europe/Copenhagen, Sascha Schumann wrote: Heavy -1 on making hardTooTypeAndEvenWorseToReadCaps a recommendation for the APIs exposed by PHP. Are you suggesting that we do not have a standard here as Derick is suggesting, or to keep the current PHP coding standard and rewrite OO extensions such as DOM in accordance with it? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Sebastian Bergmann wrote: Derick Rethans wrote: -[6] Method names follow the 'studlyCaps' This is insane. It's not. Using underscores for all native PHP functions seperates them nicely from PHP based code, eg. PEAR code. php_native_func() myFunc() or even: obj-php_native_func() obj-myFunc() Ulf -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 03 Dec 2003 11:52:35 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: php_native_func() myFunc() We are not talking about function names but methods. or even: obj-php_native_func() obj-myFunc() Quick thought, does that work with overload? See Lukas post. pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Lukas Smith wrote: Aside from that yes it will be a major problem for PEAR if objects don't follow studyCaps as this means we will have to either kick our CS or wrap objects instead of just exending them. i agree that it is way to late now for changing things in PEAR but i still think it was a bad choice in the first place (both in general and especially when taking PHPs special case sensitivity in account) regarding classes implemented by extensions i am not so sure, IMHO compatibility with existing naming schemes in previous versions of PHP is more important than PEAR CS compatibility -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS (fwd)
On Wed, 3 Dec 2003, Edin Kadribasic wrote: On Wednesday, Dec 3, 2003, at 11:33 Europe/Copenhagen, Sascha Schumann wrote: Heavy -1 on making hardTooTypeAndEvenWorseToReadCaps a recommendation for the APIs exposed by PHP. Are you suggesting that we do not have a standard here as Derick is suggesting, or to keep the current PHP coding standard and rewrite OO extensions such as DOM in accordance with it? I'm saying that I oppose recommending uglyCaps for APIs exposed by PHP, as suggested by a very vocal sub-group here. This means: No changes to the existing practice. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 12:52 PM Lukas Smith wrote: Aside from that yes it will be a major problem for PEAR if objects don't follow studyCaps as this means we will have to either kick our CS or wrap objects instead of just exending them. i agree that it is way to late now for changing things in PEAR but i still think it was a bad choice in the first place (both in general and especially when taking PHPs special case sensitivity in account) regarding classes implemented by extensions i am not so sure, IMHO compatibility with existing naming schemes in previous versions of PHP is more important than PEAR CS compatibility What exactly is there in PHP that you want to be compatible to? The amount of OO APIs in PHP atm is quite small. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
I can nuke E_STRICT altogether if u guys want. It's kind of a shame because I thought it might be nice for purists. I don't understand why it bothers ppl so much when they don't have to use it. At 12:18 PM 12/3/2003 +0100, Christian Schneider wrote: Stig S. Bakken wrote: The goal here is to assure smooth transition from PHP 4 to PHP 5 for PEAR users. To me that means not having to use version_compare() or have different versions of files for PHP 4 and 5. I think you slightly mix up PEAR developers and PEAR users but I completely agree with you. * E_ALL not including E_STRICT This kills the E_STRICT feature for both PEAR developers and PEAR users. More and more people will be using PEAR, who is still going to be able to use E_STRICT? Almost nobody. I can live with this solution but I find it a pitty to kill the feature before it is born. * var equivalent to public (ie not throwing E_STRICT) I'd prefer this for now. And before it gets forgotten: PEAR is not the only set of code which has to retain backward compatibility for a while. It's just a prominent example. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Wed, 3 Dec 2003, Andi Gutmans wrote: I can nuke E_STRICT altogether if u guys want. It's kind of a shame because I thought it might be nice for purists. I don't understand why it bothers ppl so much when they don't have to use it. Please keep it in. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Hartmut Holzgraefe [EMAIL PROTECTED] wrote: PS: can you prove that 99.% figure? i'd believe a value of maybe 80% but definetly not 99.% ;) Underscore-delimited identifiers are preferred in Ada and Ruby, while they don't seem to be in Java, Objective C, SmallTalk, C# and ECMAScript. (How about Python...?) A majority of C++ coders appear to be in favour of studlyCaps, however it was not the choice of STL. Therefore I think it'd never be a big reason for applying such rule on the PHP coding standards that most OO languages use that. IMO the proposal only makes sense in the point PEAR has grown significant enough with that style. Just my 2 yen :) Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Wednesday 03 December 2003 12.59, Derick Rethans wrote: On Wed, 3 Dec 2003, Andi Gutmans wrote: I can nuke E_STRICT altogether if u guys want. It's kind of a shame because I thought it might be nice for purists. I don't understand why it bothers ppl so much when they don't have to use it. Please keep it in. N! Don't nuke it! I don't get the point some people here are trying to make. Their point was something about that when following E_STRICT it will (maybe) not work in older versions. So that means that we need to backport every single feature in PHP 5 to every other PHP version and get everyone to upgrade, otherwise noone can use the new functions ? If you don't need the new functions you can stick to your old version and if you *DO* need the new functions, well, then use them and require those who wants to use the scripts to upgrade their PHP or don't use the scripts. Maybe those who are complaining about this should complain to their computer manufactors too that they can't use their old EDO memory modules in their brand new computers ? Don't they think about BC ?!? Hope you all got *my* point.. /Magnus -- You will pass away very quickly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Moriyoshi Koizumi wrote: Underscore-delimited identifiers are preferred in Ada and Ruby, while they don't seem to be in Java, Objective C, SmallTalk, C# and ECMAScript. (How about Python...?) i guess i finally identified the original source of studlyCaps: SmallTalk as far as i can tell from the GNU SmallTalk manual underscores are not allowed in SmallTalk identifiers so studlyCaps is the best you can get there ;) ( http://www.gnu.org/software/smalltalk/gst-manual/gst_41.html ) so we all have to use studlyCaps now as the Java class library was created by ex-SmallTalk guys? ;) A majority of C++ coders appear to be in favour of studlyCaps AFAIR this was different before the JAVA hype began with studlyCaps being rather rare in C++ code back than ... ? -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: On Wed, 03 Dec 2003 11:52:35 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: obj-php_native_func() obj-myFunc() Quick thought, does that work with overload? See Lukas post. I'm not sure if I understand this. Is there any warranty that overloaded stuff will always follow the studyCaps rule? What about a function named original_name(). Is there really a good reason why we must wrap it into OriginalName()? I'm afraid there's no one and only way. Nevertheless I preferr PHP not to use studyCaps for it's native functions/methods/whatever. It seperates the build-in functionality nicely from my code. PHP has strong roots in the C world. Most C programmers should expect that build-in labels (variables, constants, function names) use lowercase names including underscores. For those guys the absence of studyCaps is a clear indicator that they're dealing with build-in stuff. Is it really true that the entire OO-world uses study caps? C++ is a hybrid language somewhatlike PHP. As far as I know STL does not use study caps. Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). What about the existing extensions that do use studycaps (GD)? Do not change them for backward compatibility. Allow them to keep their style for the functional an the OO API (if any). Finally try to replace the entire extension with a new one. Ulf -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Hello, On Wed, 03 Dec 2003 14:02:00 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: Nevertheless I preferr PHP not to use studyCaps for it's native functions/methods/whatever. It seperates the build-in functionality nicely from my code. I like the counter and nicely move from PHP classes to the module versions depending on which configuration I work, or when I overload/extend an internal object. Is it really true that the entire OO-world uses study caps? C++ is a hybrid language somewhatlike PHP. As far as I know STL does not use study caps. See Morioshy post (python as well), most of the langages with OO features use studlycaps. STL..., well ;-) Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. A OO API can add many advantages or conveniences ways that are impossible to do with with a functionnal approach. New ways, new features, new names, nothing to make Jon Doo confused :) There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). Or drop the incosistencies instead of keeping them. What about the existing extensions that do use studycaps (GD)? Do not change them for backward compatibility. Allow them to keep their style This BC thingies in PHP5 sound always weird or silly to me (in most cases). Why in the world do we need a major release if on each case we have to take care of php4? for the functional an the OO API (if any). Finally try to replace the entire extension with a new one. Which should be the case anyway, to use the new engine features, if required. pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: This BC thingies in PHP5 sound always weird or silly to me (in most cases). Why in the world do we need a major release if on each case we have to take care of php4? One of the reasons that you don't see PHP 3 in use anymore is that the transition was so easy. Now that we have even more installations out there and a lot of open projects that run on PHP 4 it is even more important to be as BC as possible. We can break BC for a reason, but if we change existing APIs (like OCI or GD) just for CS conformance we are pushing users with existing code bases to stick with PHP 4 forever ... -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Here is more on the history of uglyCaps: http://www.testingcraft.com/cgi-bin/wiki.cgi?StudlyCaps Quote: ``Round about 1978, I remember using a terminal, said to be a European one, that displayed the underscore character as a backward arrow. Some programming language or other used that character for assignment, which made programs written in it look pretty funny on any other terminal. It also meant that programming languages couldn't sensibly use_underscores_in_multiword_variables. ´´ ``I remain firmly convinced, with no particular evidence, that that's the readon the HarderToReadStudlyCapsStyle? was invented: as a workaround. It seems to have become prevalant and cool when Smalltalk became cool (though not prevalent). Like a genetic disease, it's now so intertwined in our Digital DNA that we can't eradicate it - see the standard Java APIs, for example. ´´ Fortunately, we can avoid falling into that trap. PHP supports underscores, and terminals which cannot display the character correctly don't prevail any longer. So, studlyCaps fans, join the modern times where it is permittable to use underscores as word seperators. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Quoting Andi Gutmans [EMAIL PROTECTED]: I can nuke E_STRICT altogether if u guys want. It's kind of a shame because I thought it might be nice for purists. I don't understand why it bothers ppl so much when they don't have to use it. I am with Derick, it should be in. The non-purist won't use it! The non-purists even now doesn't use E_ALL, they don't have E_NOTICEs enabled. Andrey Just my 0.046BGL :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Thanks for the history, always funny :) On Wed, 3 Dec 2003 15:05:19 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: Fortunately, we can avoid falling into that trap. PHP supports underscores, and terminals which cannot display the character correctly don't prevail any longer. If you consider this is the main issue... :P So, studlyCaps fans, join the modern times where it is permittable to use underscores as word seperators. OK, then mail to java (for the java binder), microsoft (com binder and w32 ext), libxml (and related tools), w3c (dom and others std), python (python binder), postgres, wxwindows (should come as well soon or later)... teams and ask them to move to the modern times as well ;-) pierre who failed to do not start this flame again -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: OK, then mail to java (for the java binder), microsoft (com binder and w32 ext), libxml (and related tools), w3c (dom and others std), python (python binder), postgres, wxwindows (should come as well soon or later)... teams and ask them to move to the modern times as well ;-) why mail? why not just lead by example? ;) -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003 15:05:19 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: Fortunately, we can avoid falling into that trap. PHP supports underscores, and terminals which cannot display the character correctly don't prevail any longer. If you consider this is the main issue... :P The point is that uglyCaps are backwards, a hack/workaround for a missing feature in a language. uglyCaps have no inherent advantage which should be considered by those advocating their widespread usage. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: On Wed, 03 Dec 2003 14:02:00 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. A OO API can add many advantages or conveniences ways that are impossible to do with with a functionnal approach. New ways, new features, new names, nothing to make Jon Doo confused :) There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). Or drop the incosistencies instead of keeping them. Ok, drop the studyCaps. What about the existing extensions that do use studycaps (GD)? Do not change them for backward compatibility. Allow them to keep their style This BC thingies in PHP5 sound always weird or silly to me (in most cases). Why in the world do we need a major release if on each case we have to take care of php4? We do have to take care. Fear the installed code base. for the functional an the OO API (if any). Finally try to replace the entire extension with a new one. Which should be the case anyway, to use the new engine features, if required. pierre -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de Pierre-Alain Joye wrote: Hello, On Wed, 03 Dec 2003 14:02:00 +0100 Ulf Wendel [EMAIL PROTECTED] wrote: Is it really true that the entire OO-world uses study caps? C++ is a hybrid language somewhatlike PHP. As far as I know STL does not use study caps. See Morioshy post (python as well), most of the langages with OO features use studlycaps. STL..., well ;-) Well, shall we use spaces or tabs withing our code? I think most people preferr spaces... It's not really who takes the one or the other way. I could easily argue against Python? Phyton, sorry - I'm not talking anmimals. Java? I preferr tea an real computer languages like C++. In the end it boild down to a a matter of personal taste. I can arrange myself with both naming conventions. Most PHP extension have a functional interface. If some extension will become an OO API in the future this API should not differ from the functional API. I don't see a good reason why I we should teach everybody that the OO API uses different function (method) names than the well known functional interfaces. No need to confuse everybody. A OO API can add many advantages or conveniences ways that are impossible to do with with a functionnal approach. New ways, new features, new names, nothing to make Jon Doo confused :) I'm not arguing against OO interfaces. I'm requesting consistency with existing APIs. There's enough inconsistency in the extension APIs. Do not introduce even more breaks. Let the functional and the OO interface use the same labels (as far as possible). Or drop the incosistencies instead of keeping them. That's what I'm suggesting when it comes to new extension. Leave the old extension untouched for BC, try to rewrite it and convince people that you've done a good job. Such a good job as Georg (Richter) did with the mysqli extension. But: leave the old (current) extension untouched. As Hartmut said BC is a strength not a weakness. Fear the installed code base and be very careful with API changes. Be extremly careful with changes that are caused by a discussion on tastes. However this is not why I raised my voice. I'd like PHP to keep it's underscore-delimited lowercase identifiers for all kind of build-in functionality. It helps me reading and understanding my souce. All my PHP functions use studyCaps. Most build-in stuff uses underscores. This rule should be useful for beginners as well. Whenever you see a function (method) that uses underscores look it under php.net/function_name. It does not matter if it's a function or method, look it up under php.net/function_name. Whenever you spy a function (method) that uses studyCaps, try to find it's documentation on pear.php.net or... Ulf -- Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib), WWE Hamburg, http://www.ulf-wendel.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003 15:44:52 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: The point is that uglyCaps are backwards, a hack/workaround for a missing feature in a language. uglyCaps have no inherent advantage which should be considered by those advocating their widespread usage. Well, as (hopefully) a last post from me in this thread, the fact is the UglyCaps is widely used, with PHP and others OO langages. The fact is that is somehow a de facto standard and ease our life to bind/port/extend/whatever existing codes/applications/libraries using php. And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? pierre. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Pierre-Alain Joye wrote: And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? readability -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Fixed. bison --output=Zend/zend_ini_parser.\ -v -d -p ini_ Zend/zend_ini_parser .y Zend/zend_ini_parser.y: conflicts: 4 shift/reduce Zend/zend_ini_parser.y: warning: conflicting outputs to file `Zend/zend_ini_pars er.\\' bison: cannot open file `Zend/zend_ini_parser.\': No such file or directory NMAKE : fatal error U1077: 'bison' : Rueckgabe-Code '0x1' Stop. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:03 PM Pierre-Alain Joye wrote: And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? readability I dont find it unreadable. Anyways this is not a point you can argue about .. you could make a poll about it .. So people began using studlyCaps because underscores weren't handled by the language (that is what people here have said anyways). Whatever the reason it might make sense to stop and think for a second what we envision to be to primary type of OO APIs we will have to deal with. There are a number of APIs that are simple wrappers around other OO APIs and then there are those that we create ourselves. I think it makes sense to try and keep the APIs as consistent as possible. As all parties seem to agree DOM should be studlyCaps. So what about other OO APIs will we wrap? What are we most likely going to encounter .. studlyCaps or not? Then there is the question of the ratio of APIs we wrap and APIs we define ourselves. This should also affect our decision of if we can be more modern or have to accept the realities of the outside world (whatever they may be). Alternative we can say that the realities of the outside world don't matter to use in this case, because after all we strive to be better with PHP than the rest of the world. So maybe it is worth breaking with the rest of the world. Maybe it is worth trying to stay as compatible as possible. Then there is the issue BC, or acknowledging PHPs history. On the one side we have a standard for procedural PHP code and very few OO code already out there. On the other we have a clear dominance (again I don't have statistical data to backup this claim) of studylCaps in userland OO PHP code. So please let us go at this without this what is more modern approach. Let us remind ourselves that PHP is a glue language. But also let us remind ourselves that PHP aims to be better than the rest. Finally everybody that talks about how the OO API should be step back and think if they actually intent to write OO PHP code and if it could be that they are fighting for the look of something they will never use anyways. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Well, as (hopefully) a last post from me in this thread, the fact is the UglyCaps is widely used, with PHP and others OO langages. The fact is that is somehow a de facto standard and ease our life to bind/port/extend/whatever existing codes/applications/libraries using php. Look, my stance is this. We don't need to repeat the mistakes of others for our own APIs. Which means I object to the suggestion that studlyCaps ever become a recommendation for creating new APIs in PHP (regardless of whether it is a function or method name). This however leaves the door open for people writing bindings to choose either way. And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? This is all about readability. Both studlyCaps and foo_bar try to preserve word separation. studlyCaps stems from the time where one could not use non-alphanumerical characters for achieving that job. So, because they had no better tools, the users agreed to uppercase the first letter of a word to signal the beginning of a new word. However, since then tools have evolved to the point where the word boundary can actually be signalled by other characters. Which means that users have more choices now. And considering the options, I choose the one which is easier to read. ThisIsJustAnotherSentenceWithStudlyCapsWhichYouWillFindHardToFollow. And_this_is_another_sentence_which_should_be_quick_to_comprehend. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Do you think this inconsistency is worth it, even if it turns out that most of our bindings turn out to choose studyCaps? Certainly. And I am pretty sure that many binding authors will understand why uglyCaps are largely inferior in the area of comprehension. No doubt the non studlyCaps version is easier to read (btw in the studlyCaps version the first char should be lowercased). However is this a real scenario? How many words will there be in a method name? I have seen Windows identifiers which are nearly that length. I don't mind elaborated identifiers, but whatever their length is, they need to be readable. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Lukas Smith wrote: Pierre-Alain Joye wrote: And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? readability I dont find it unreadable. it is not unreadable but it is definetly *less* readble -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:31 PM Lukas Smith wrote: Pierre-Alain Joye wrote: And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? readability I dont find it unreadable. it is not unreadable but it is definetly *less* readble The funny thing before I started developing in PEAR I wrote very little OO code. And I found the PEAR CS annoying as hell. But now I don't have a problem at all with it. Apparently a bunch of other people don't have a problem with studlyCaps. So much so that they are still using it even in modern languages that can handle underscores in method names. So maybe it is just a matter of being used to either form. Now since PHP is developer driven and most of the developers are used to underscores the question is if the fact that a lot of users for OO will be quite used to studlyCaps for OO (actually not using studlyCaps might be confusing to them) matters. The fact that PEAR has a serious problem extending non studlyCap objects is probably something a lot of people in PHP core don't care about. And I guess it shouldn't be THE reason to go either way. But it shouldn't be brushed off totally either. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003 16:16:14 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: Well, as (hopefully) a last post from me in this thread, the fact is theUglyCaps is widely used, with PHP and others OO langages. The fact is that is somehow a de facto standard and ease our life to bind/port/extend/whatever existing codes/applications/libraries using php. Look, my stance is this. We don't need to repeat the mistakes of others for our own APIs. Yeah and we are the kings and we know what is good or not... br ;-) Which means I object to the suggestion that studlyCaps ever become a recommendation for creating new APIs in PHP (regardless of whether it is a function or method name). This however leaves the door open for people writing bindings to choose either way. If we keep the doors open then welcome to even more inconsistencies. A contrario, using the wider And except StudlyCaps is ugly and foo_bar is modern, any realistic and objective pros to keep foo_bar? This is all about readability. imho, this argument is weightless regarding the cons. Improving (so few...) readability by decreasing consistency with external tools/apps or the waste majority of existing codes is (imho again) the worst thing to do. Thinking about all the additionnal work only to make your eyes happy is even worst to me. End of discussion here, I cannot argue anymore against such aesthetic arguments... pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
The fact that PEAR has a serious problem extending non studlyCap objects is probably something a lot of people in PHP core don't care about. Please elaborate. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Sascha Schumann [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:39 PM The fact that PEAR has a serious problem extending non studlyCap objects is probably something a lot of people in PHP core don't care about. Please elaborate. Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS requires that I use studlyCaps, then I have a problem. Essentially I can only wrap and not extend. I guess you can say this is our problem however, since we could also choose to loosen our CS to allow underscores. I don't feel that having to ways in there is the way to go. I prefer to stay with one which results in the fewest breaks with the outside world. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: Fixed. Yes, but now it fails with NMAKE : fatal error U1073: 'ext\standard\parsedate.c' konnte nicht erstellt werd en Stop. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003, Lukas Smith wrote:
From: Sascha Schumann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:39 PM
The fact that PEAR has a serious problem extending non studlyCap objects
is
probably something a lot of people in PHP core don't care about.
Please elaborate.
Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS
requires that I use studlyCaps, then I have a problem. Essentially I can
only wrap and not extend.
Uh? That works just fine...
class Foo_Bar extends foo2_bar {
}
No problem at all.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:46 PM
On Wed, 3 Dec 2003, Lukas Smith wrote:
From: Sascha Schumann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:39 PM
The fact that PEAR has a serious problem extending non studlyCap
objects
is
probably something a lot of people in PHP core don't care about.
Please elaborate.
Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS
requires that I use studlyCaps, then I have a problem. Essentially I can
only wrap and not extend.
Uh? That works just fine...
class Foo_Bar extends foo2_bar {
}
No problem at all.
We are talking about methods names here.
Regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
On Wed, 3 Dec 2003, Lukas Smith wrote: From: Sascha Schumann [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:39 PM The fact that PEAR has a serious problem extending non studlyCap objects is probably something a lot of people in PHP core don't care about. Please elaborate. Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS requires that I use studlyCaps, then I have a problem. Essentially I can only wrap and not extend. I guess you can say this is our problem however, since we could also choose to loosen our CS to allow underscores. Agreed. I don't feel that having to ways in there is the way to go. I prefer to stay with one which results in the fewest breaks with the outside world. You apparently live in an alternative outside world. In mine, there are 99% C bindings where studlyCaps virtually do not exist. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Lukas Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:46 PM
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:46 PM
On Wed, 3 Dec 2003, Lukas Smith wrote:
From: Sascha Schumann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 4:39 PM
The fact that PEAR has a serious problem extending non studlyCap
objects
is
probably something a lot of people in PHP core don't care about.
Please elaborate.
Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS
requires that I use studlyCaps, then I have a problem. Essentially I
can
only wrap and not extend.
Uh? That works just fine...
class Foo_Bar extends foo2_bar {
}
No problem at all.
We are talking about methods names here.
Just to clarify:
Yes there are no technical issues.
There is only the fact that PEAR has decided to have a consistent OO API
based on studlyCaps.
Regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mingw32
Hi Wez, now that the dependency on VC has been dropped, what would it take to get mingw32 build support? - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: Sascha Schumann [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:53 PM On Wed, 3 Dec 2003, Lukas Smith wrote: From: Sascha Schumann [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 4:39 PM The fact that PEAR has a serious problem extending non studlyCap objects is probably something a lot of people in PHP core don't care about. Please elaborate. Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS requires that I use studlyCaps, then I have a problem. Essentially I can only wrap and not extend. I guess you can say this is our problem however, since we could also choose to loosen our CS to allow underscores. Agreed. I don't feel that having to ways in there is the way to go. I prefer to stay with one which results in the fewest breaks with the outside world. You apparently live in an alternative outside world. In mine, there are 99% C bindings where studlyCaps virtually do not exist. And here is the other difference in opinion: To me procedural APIs bound to an OO API break their heritage and so I don't have a problem of going to studlyCaps. Actually I think it is even an advantage because it makes me differentiate procedural code from OO code more easily. But now we are getting into aesthetics again :-) So it goes .. I don't feel I have anything to add beyond what I have said so far and I hope I haven't wasted peoples time (even if the only value was to reassure the opinion that studlyCaps is not for PHP). Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mingw32
On Wed, 3 Dec 2003 17:01:23 +0100 (CET) Sascha Schumann [EMAIL PROTECTED] wrote: Hi Wez, now that the dependency on VC has been dropped, what would it take to get mingw32 build support? Should be really great :). By the way (or a bit OT), I got little little success by running console VC tools using wine on linux, anyone experencied with these tools? pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
Lukas Smith wrote: Actually I think it is even an advantage because it makes me differentiate procedural code from OO code more easily. that would be an argument for C++ where calls to member functions look exactly like calls to functions from the global scope in PHP the difference becomes rather clear due to the required $this- prefix -- Hartmut Holzgraefe [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Andi Gutmans wrote: I can nuke E_STRICT altogether if u guys want. It's kind of a shame because I thought it might be nice for purists. I don't understand why it bothers ppl so much when they don't have to use it. Please keep it... It will be usefull for people willing to write good PHP5 code. It's about the same thing with E_NOTICES in PHP4. Not alot of people care about notices, but if you want to build a strong application, you will soon turn them on. Just my 2.8¢, eh? Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mingw32
When I tried to enable win32 specific extensions (such as COM) under cygwin, I found that a lot of the win32 api headers were missing, so the build failed. I suspect that the same problem will manifest with mingw32. It's nothing that downloading the platform SDK won't solve, but if you download that, you've got the MS build tools anyway. I don't plan to look at mingw32 myself, and I don't want to deal with patches for it until I've completed the features I have planned for the build system; once done, adding mingw support should be reasonably simple (just change the object and library suffixes and compiler flags...). --Wez. now that the dependency on VC has been dropped, what would it take to get mingw32 build support? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mingw32
On Wed, 3 Dec 2003, Wez Furlong wrote: When I tried to enable win32 specific extensions (such as COM) under cygwin, I found that a lot of the win32 api headers were missing, so the build failed. Cygwin is a Unix portability layer, not a win32. :) mingw's header set should be fairly complete. http://www.mingw.org/mingwfaq.shtml#faq-w32api I don't plan to look at mingw32 myself, and I don't want to deal with patches for it until I've completed the features I have planned for the build system; once done, adding mingw support should be reasonably simple (just change the object and library suffixes and compiler flags...). Will there be an abstraction similar to our current m4 infrastructure? (I have not looked at the .js yet) - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mingw32
When I tried to enable win32 specific extensions (such as COM) under cygwin, I found that a lot of the win32 api headers were missing, so the build failed. Cygwin is a Unix portability layer, not a win32. :) Sure, but you can use the win32 api from there, and some of the headers used by COM are not present in cygwin install. Will there be an abstraction similar to our current m4 infrastructure? (I have not looked at the .js yet) Although there isn't right at this moment, there will be. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Hello Andi, Wednesday, December 3, 2003, 12:57:19 PM, you wrote: I can nuke E_STRICT altogether if u guys want. It's kind of a shame because I thought it might be nice for purists. I don't understand why it bothers ppl so much when they don't have to use it. Args, please let it in. It helps for ppl writing php5 only code - it helps those ppl who didn't care about the non existing oo features in php4 and want to use good php5 oo code. And again it doesn't hurt anybody with php4 concerns (bc and whatever) since we disabled it by default and not include it in E_ALL. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: You also need the Microsoft build tools (cl.exe, link.exe and nmake.exe). These are freely available as part of the Platform SDK, but also come with VC++/Visual Studio. Just to be sure... I have VC6, so I don't need those, but are you talking about this SDK? http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ If this is the good link, should we put it in the Building PHP with Windows part of the manual? I can always add it (IIRC I have karma) if you don't have the time to. Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] browscap and nesting level too deep (bug #25916)
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_browser() function and is the most visited page.
So it must be a multithreading issue (NSAPI is a multithreading webserver).
And I have an idea:
Line 257 uses:
zend_hash_apply_with_arguments(browser_hash, (apply_func_args_t)
browser_reg_compare, 2, lookup_browser_name, found_browser_entry);
This is the only function in this context in zend_hash.c which uses the
Recursion protection with
#define
HASH_PROTECT_RECURSION(ht)
\
if ((ht)-bApplyProtection)
{
\
if ((ht)-nApplyCount++ = 3)
{
\
zend_error(E_ERROR, Nesting level too deep -
recursive dependency?); \
}
\
}
The browser hashtable is a global variable in browscap.c and can be used by
more than one call to get_browser() even at the same time. So if one
zend_hash_apply_with_arguments() locks the hashtable and a second and third
thread tries to do that you will get the error, because (ht)-nApplyCount++
raises and raises...
This evening I will try to put a mutex at the beginning of get_browser to
prevent more threads running at the same time there. But as I see this,
this zend_hash_apply function is used very often could there be other
effects if a global variable is a hashtable?
Only one question: Is there a special PHP way to use mutexes? I am not
familar in Zend programming (I do only SAPI...)
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Yes, thats the one, but please don't do that (yet!). I want to stabilize things a little before it goes public; I don't mind dealing with a handful of the core developers, but certainly can't handle people asking me how to install the SDK etc. etc. right now. --Wez. You also need the Microsoft build tools (cl.exe, link.exe and nmake.exe). These are freely available as part of the Platform SDK, but also come with VC++/Visual Studio. Just to be sure... I have VC6, so I don't need those, but are you talking about this SDK? http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ If this is the good link, should we put it in the Building PHP with Windows part of the manual? I can always add it (IIRC I have karma) if you don't have the time to. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
Hello Uwe,
Wednesday, December 3, 2003, 6:06:13 PM, you wrote:
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_browser() function and is the most visited page.
So it must be a multithreading issue (NSAPI is a multithreading webserver).
And I have an idea:
Line 257 uses:
zend_hash_apply_with_arguments(browser_hash, (apply_func_args_t)
browser_reg_compare, 2, lookup_browser_name, found_browser_entry);
This is the only function in this context in zend_hash.c which uses the
Recursion protection with
#define
HASH_PROTECT_RECURSION(ht)
\
if ((ht)-bApplyProtection)
{
\
if ((ht)-nApplyCount++ = 3)
{
\
zend_error(E_ERROR, Nesting level too deep -
recursive dependency?); \
}
\
}
The browser hashtable is a global variable in browscap.c and can be used by
more than one call to get_browser() even at the same time. So if one
zend_hash_apply_with_arguments() locks the hashtable and a second and third
thread tries to do that you will get the error, because (ht)-nApplyCount++
raises and raises...
This evening I will try to put a mutex at the beginning of get_browser to
prevent more threads running at the same time there. But as I see this,
this zend_hash_apply function is used very often could there be other
effects if a global variable is a hashtable?
Only one question: Is there a special PHP way to use mutexes? I am not
familar in Zend programming (I do only SAPI...)
Why not simply use external iteration? You don't add or modify the browser
list right?
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
We have thread-safe hashes in php5; browscap should probably
use one of those there. If you want to roll your own protection,
take a look at tsrm_mutex_lock() and tsrm_mutex_unlock() and how
they are used in ext/yaz.
--Wez.
- Original Message -
From: Uwe Schindler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 5:06 PM
Subject: [PHP-DEV] browscap and nesting level too deep (bug #25916)
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or
not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_browser() function and is the most visited page.
So it must be a multithreading issue (NSAPI is a multithreading
webserver).
And I have an idea:
Line 257 uses:
zend_hash_apply_with_arguments(browser_hash, (apply_func_args_t)
browser_reg_compare, 2, lookup_browser_name, found_browser_entry);
This is the only function in this context in zend_hash.c which uses the
Recursion protection with
#define
HASH_PROTECT_RECURSION(ht)
\
if ((ht)-bApplyProtection)
{
\
if ((ht)-nApplyCount++ = 3)
{
\
zend_error(E_ERROR, Nesting level too deep -
recursive dependency?); \
}
\
}
The browser hashtable is a global variable in browscap.c and can be used
by
more than one call to get_browser() even at the same time. So if one
zend_hash_apply_with_arguments() locks the hashtable and a second and
third
thread tries to do that you will get the error, because
(ht)-nApplyCount++
raises and raises...
This evening I will try to put a mutex at the beginning of get_browser to
prevent more threads running at the same time there. But as I see this,
this zend_hash_apply function is used very often could there be other
effects if a global variable is a hashtable?
Only one question: Is there a special PHP way to use mutexes? I am not
familar in Zend programming (I do only SAPI...)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
On 2003/12/04, at 2:06, Uwe Schindler wrote: This evening I will try to put a mutex at the beginning of get_browser to prevent more threads running at the same time there. But as I see this, this zend_hash_apply function is used very often could there be other effects if a global variable is a hashtable? Only one question: Is there a special PHP way to use mutexes? I am not familar in Zend programming (I do only SAPI...) Did you take a look at zend_ts_hash (only in php5) and tsrm_mutex_*() ? I'm not quite sure if the facility is enough tested and really thread-safe though. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: Yes, thats the one, but please don't do that (yet!). I want to stabilize things a little before it goes public; I don't mind dealing with a handful of the core developers, but certainly can't handle people asking me how to install the SDK etc. etc. right now. Ooops.. I do understand that ;) Well, let me know if I can help you when things get stabilized. In the meantime, do we still have to update a bunch of .dsp/.dsw to rename all php4* files to php5*? Or does this new configuration script take care of this? Edin was talking about this problem 2-3 weeks ago. Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
One solution (attached is the patch, if nobody has someone against it I
will apply it):
I switch off the recursion protection for the browscap hash in
zend_hash_init_ex because this hash has no recursive things in it and is
not modified after it is created.
Uwe
At 18:06 03.12.2003, Uwe Schindler wrote:
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_browser() function and is the most visited page.
So it must be a multithreading issue (NSAPI is a multithreading
webserver). And I have an idea:
Line 257 uses:
zend_hash_apply_with_arguments(browser_hash, (apply_func_args_t)
browser_reg_compare, 2, lookup_browser_name, found_browser_entry);
This is the only function in this context in zend_hash.c which uses the
Recursion protection with
#define HASH_PROTECT_RECURSION(ht) \
if ((ht)-bApplyProtection) { \
if ((ht)-nApplyCount++ = 3) { \
zend_error(E_ERROR, Nesting level too deep -
recursive dependency?); \
} \
}
The browser hashtable is a global variable in browscap.c and can be used
by more than one call to get_browser() even at the same time. So if one
zend_hash_apply_with_arguments() locks the hashtable and a second and
third thread tries to do that you will get the error, because
(ht)-nApplyCount++ raises and raises...
This evening I will try to put a mutex at the beginning of get_browser to
prevent more threads running at the same time there. But as I see this,
this zend_hash_apply function is used very often could there be other
effects if a global variable is a hashtable?
Only one question: Is there a special PHP way to use mutexes? I am not
familar in Zend programming (I do only SAPI...)
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
Index: ext/standard/browscap.c
===
RCS file: /repository/php-src/ext/standard/browscap.c,v
retrieving revision 1.60.2.15
diff -u -r1.60.2.15 browscap.c
--- ext/standard/browscap.c 13 Aug 2003 23:39:03 - 1.60.2.15
+++ ext/standard/browscap.c 3 Dec 2003 17:15:01 -
@@ -149,7 +149,7 @@
zend_file_handle fh;
memset(fh, 0, sizeof(fh));
- if (zend_hash_init(browser_hash, 0, NULL, (dtor_func_t)
browscap_entry_dtor, 1)==FAILURE) {
+ if (zend_hash_init_ex(browser_hash, 0, NULL, (dtor_func_t)
browscap_entry_dtor, 1, 0)==FAILURE) {
return FAILURE;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
I'd like this system to replace the .dsp's ready for when PHP 5 goes gold; I'm not sure what the others think. However, I don't think we have time to get it working for beta 3, so someone still needs to edit all those .dsp files, and change php4 to php5 in main/config.w32.h for the install dir. --Wez. Well, let me know if I can help you when things get stabilized. In the meantime, do we still have to update a bunch of .dsp/.dsw to rename all php4* files to php5*? Or does this new configuration script take care of this? Edin was talking about this problem 2-3 weeks ago. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Hi Wez: On Wed, Dec 03, 2003 at 05:28:43PM -, Wez Furlong wrote: I certainly can't support someone who has never heard of it before install it :-) I'm just asking where you downloaded it from, please. For example, did you use the aforementioned URI but with IE? Or do you have some other URI? Maybe, but I don't have the time to help you there I'm afraid. No sweat. I'm not looking for help. Just wondering if you knew if it would work. So, the answer is maybe. I'll try it out -- when I get the Platform SDK installed :) -- and let folks know what happens. Thanks, --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
I'm just asking where you downloaded it from, please. For example, did you use the aforementioned URI but with IE? Or do you have some other URI? I didn't download it; I have VC6 and VS.Net 2003. Olivier Hill posted a link to the correct page which is one of those you mentioned in your MS rant iirc. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: Olivier Hill posted a link to the correct page which is one of those you mentioned in your MS rant iirc. And you need IE 5+ to access the page.. Since it's ActiveX powered with Famous Microsoft Auto-Install via the web crap. Browsing with Mozilla will only give you a warning. Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CODING_STANDARDS
On Wed, 3 Dec 2003, Edin Kadribasic wrote: On Wednesday, Dec 3, 2003, at 10:12 Europe/Copenhagen, Derick Rethans wrote: derick Wed Dec 3 04:12:39 2003 EDT Modified files: /php-src CODING_STANDARDS Log: - I am sure I reverted this before No you didn't. Care to elaborate on this change? What I understood from quickly reading all posts, this was just a removal of requirement to use suckCaps ? So anyone is free to do either..why is this a problem? (IMO, it might be clearer if the engine used the non-OO way, thus you'd be able to stick your finger on the code and tell immediately what is internal and what is not..) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: However, I don't think we have time to get it working for beta 3, so someone still needs to edit all those .dsp files, and change php4 to php5 in main/config.w32.h for the install dir. Maybe we could commit this file for PHP5. As for the dsp/dsw, we have to include new file in CVS. Is someone able to rename all files on the server to php4*.dsp -- php5*.dsp? After this step, a simple find/replace should do the trick. Am I mistaken? Edin? Wez? Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) --- main/config.w32.h 29 Nov 2003 22:48:41 - 1.81 +++ main/config.w32.h 3 Dec 2003 18:00:15 - @@ -7,17 +7,17 @@ /* Default PHP / PEAR directories */ #define CONFIGURATION_FILE_PATH php.ini -#define PEAR_INSTALLDIR c:\\php4\\pear -#define PHP_BINDIR c:\\php4 +#define PEAR_INSTALLDIR c:\\php5\\pear +#define PHP_BINDIR c:\\php5 #define PHP_CONFIG_FILE_PATH (getenv(SystemRoot))?getenv(SystemRoot): #define PHP_CONFIG_FILE_SCAN_DIR -#define PHP_DATADIR c:\\php4 -#define PHP_EXTENSION_DIR c:\\php4 -#define PHP_INCLUDE_PATH .;c:\\php4\\pear -#define PHP_LIBDIR c:\\php4 -#define PHP_LOCALSTATEDIR c:\\php4 -#define PHP_PREFIX c:\\php4 -#define PHP_SYSCONFDIR c:\\php4 +#define PHP_DATADIR c:\\php5 +#define PHP_EXTENSION_DIR c:\\php5 +#define PHP_INCLUDE_PATH .;c:\\php5\\pear +#define PHP_LIBDIR c:\\php5 +#define PHP_LOCALSTATEDIR c:\\php5 +#define PHP_PREFIX c:\\php5 +#define PHP_SYSCONFDIR c:\\php5 /* Enable / Disable BCMATH extension (default: enabled) */ #define WITH_BCMATH 1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Wed, 3 Dec 2003, Stig S. Bakken wrote: What we're trying to avoid is to force every package maintainer to roll PHP 5 specific releases for packages that still support PHP 4. Smooth transition requires that one package at a time can be transitioned, or we would create a dependency mess out of this world. Erm..I don't get this..E_STRICT is now OFF by default so how can it cause problems..? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] __clone arguments
Sorry if it has been discussed before, but how is the
question about __clone accept arguments ???
It would permit a better control when clonning
objects, like dinamically setting properties.
Sure its is possible using wrappers, but would be
better if the function supports that.
class clonable{
public $age;
public $b;
// function __clone($a){
// if ($a) $this-age = $a;
// else $this-age = $that-age;
// }
}
$molly = new clonable;
$molly-age = 1;
$dolly = $molly-__clone(0);
echo $dolly-age;
if ($dolly == $molly) echo equal: TRUE;
else {
var_dump($dolly);
var_dump($molly);
}
if ($dolly === $molly) echo identical: TRUE;
else {
var_dump($dolly);
var_dump($molly);
}
Eduardo R. Maciel
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
Uwe Schindler wrote: One solution (attached is the patch, if nobody has someone against it I will apply it): I switch off the recursion protection for the browscap hash in zend_hash_init_ex because this hash has no recursive things in it and is not modified after it is created. Uwe That will probably do it. I'm going to try and reproduce this with and without the patch today on our Solaris box and I'll see what I get. I've been swamped recently and haven't been able to give this a good look. (The browscap extension really needs to be gutted, but at least it works, for the most part...) Going to go give this a try now... J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: browscap and nesting level too deep (bug #25916)
Uwe, I'm having problems reproducing the error. I tried hammering a get_browser() function with apachebench a couple of times with the options (-n 1000 -c 25) and they all returned the same content length, so I'm assuming there was no error in any of them. I'm using iPlanet-WebServer-Enterprise/6.0 on Solaris 8 SPARC. Nothing strange about the set up, I think. What was the configuration line you used? I'll try to get my set up as close as possible and go from there. J Uwe Schindler wrote: Today I got the error from bug #25916 several times on our webserver. Looking through the code I found out the following: * It depends NOT on the fact if there is a parameter to get_browser() or not * It happens sometimes when server is very heavy loaded, the homepage of the domain uses the get_browser() function and is the most visited page. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __clone arguments
It doesn't accept arguments. An object should know how to clone itself
without additional information. If you want a method which does something
other than cloning then define your own method.
Andi
At 10:14 AM 12/3/2003 -0800, Eduardo R. Maciel wrote:
Sorry if it has been discussed before, but how is the
question about __clone accept arguments ???
It would permit a better control when clonning
objects, like dinamically setting properties.
Sure its is possible using wrappers, but would be
better if the function supports that.
class clonable{
public $age;
public $b;
// function __clone($a){
// if ($a) $this-age = $a;
// else $this-age = $that-age;
// }
}
$molly = new clonable;
$molly-age = 1;
$dolly = $molly-__clone(0);
echo $dolly-age;
if ($dolly == $molly) echo equal: TRUE;
else {
var_dump($dolly);
var_dump($molly);
}
if ($dolly === $molly) echo identical: TRUE;
else {
var_dump($dolly);
var_dump($molly);
}
Eduardo R. Maciel
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] StudlyCaps
Hey, I think we should come to closure on this discussion because it's becoming hard to catch up with. I'd like to finalize this issue for PHP (the C part) so that we can release Beta 3. I think what PEAR does is really up to the PEAR dev team (although I think it would be nice for them to be consistent with PHP itself). The facts are the following: a) Existing PHP functions use underscores. b) Some external object models such as Java use StudlyCaps. The immediate decision we have to make is if PHP's OOP functionality (class names and method names) use underscores or studly caps. I think for (b) (interfacing with external object models) the answer is obvious. Do what you need to do to expose the external object model, and thus use StudlyCaps where applicable. That's kind of obvious IMO. If the external object model has underscores then use that. However, I think what we do with PHP's object model is not that obvious. Although I'm quite indifferent to these when I program (I usually use the most popular method with the language I'm using) I think there are two advantages for using underscores: a) functions already use them thus we are consistent across the board (something we historically don't excel in). b) StudlyCaps doesn't know how to deal with one character words such as IAmAndi. which would be something like i_am_andi in underscores. You often find yourself having to do two capitol letters one after another and it ruins the whole thing. The same thing happens with acronyms, for example, PHPObject (no differentiation between PHP and Object). I think that even if some OOP developers prefer the studly caps, using underscores might even have an advantage of differentiating between PHP methods and the user's methods. Let's not turn this into a religious war. I think everyone here understands the pros/cons. Let's try and reach a decision quickly and make sure we adopt it, because indecision is worse than making the wrong decision :) I apologize for the long letter. Please don't copy me :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
My vote is on StudlyCaps for class method and attribute names. This is the standard in many OO languages (SmallTalk, C#, Java - as a parenthetical I don't think that SmallTalks adoption of StudlyCaps (one of the first I'm aware of) had anything to do with _ rendering), and while we do not need to mimic other languages, adopting common conventions is a good thing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
I know the valids decision votes will be from the core developers (wich I am not). But I´d like to expose my suggestion: - PHP object oriented parts, like classnames, methods, atributes, etc could use studlyCaps as almost whole world use to with OO code. - Php procedural parts, like functions, vars, constants, etc could use underscore as almost the whole world use to with not OO code. Since PHP is a mixed language (procedural and Object Oriented) It would even help to diferentiate each paradigm. The way it would be easy to know when a external module supports OO features for example. And as Andi said, interfacing with external modules and interfacing with other technologies are growing up, and would help if it works like those other technologies. In the other hand, using underscores where code is not OO, would make clear to see that you are using the procedural way. Just imagine how complicated will it be if PHP programmers has to use several OO modules, and some of them use underscores, PEAR using studlycaps, another framework using undercores too, and other using studly, all Object Oriented. What a mess Defining all OO parts of PHP (and recomending it to external modules) as studlyCaps would follow a tendency which ALREADY EXISTS and not force all existant PHP OO code to be rewritten. And would keep things in order. Easy to manage. In the other hand, defining the use of underscores will break what already exists (about OO Code) and probably won´t be accepted as a consensus. Means that what I sad above (the messy code) can happen. IMO it would the best to do in this situation. __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Wed, 2003-12-03 at 15:58, George Schlossnagle wrote: My vote is on StudlyCaps for class method and attribute names. This is the standard in many OO languages (SmallTalk, C#, Java - as a parenthetical I don't think that SmallTalks adoption of StudlyCaps (one of the first I'm aware of) had anything to do with _ rendering), and while we do not need to mimic other languages, adopting common conventions is a good thing. +1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen variable name makes all the difference. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
If the votes already takes place, I vote on studlyCaps as a recommendation for PHP OO API, because of consistency with the existing PEAR conventions. I like underscore_delimited_style, but embracing two different standards will definitely disgust not a few number of people. Neither Readability nor familiarity does matter here. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Hello Andi, i am pro studlyCaps. 1st it eases PEAR development towards php5. 2nd we choose not to do so as we couldn't show errors and all in original casing, now we can we decided to use studlyCaps and we agreed upon even in our CODING_STYLE (and we did whether or not that rule was removed today). 3rd using different naming conventions in procedural and oo code seems to be a pro from my point of view, too. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
+1 on studlyCaps pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Thu, 4 Dec 2003, Moriyoshi Koizumi wrote: If the votes already takes place, I vote on studlyCaps as a recommendation for PHP OO API, because of consistency with the existing PEAR conventions. I like underscore_delimited_style, but embracing two different standards will definitely disgust not a few number of people. haha, with these suckyCaps we have two different styles for core-php functions; that's worse and that's what we *should* care about. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Wed, 3 Dec 2003, Marcus Boerger wrote: 2nd we choose not to do so as we couldn't show errors and all in original casing, now we can we decided to use studlyCaps and we agreed upon even in our CODING_STYLE (and we did whether or not that rule was removed today). That's bollocks. I put that 'rule' in after the PEAR meeting; it had NOTHING to do with any discussion on the internals@ list. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
George Schlossnagle wrote: My vote is on StudlyCaps for class method and attribute names. This is the standard in many OO languages (SmallTalk, C#, Java - as a parenthetical I don't think that SmallTalks adoption of StudlyCaps (one of the first I'm aware of) had anything to do with _ rendering), and while we do not need to mimic other languages, adopting common conventions is a good thing. On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly foobarbaz) and Ruby (mostly foo_bar_baz). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
-1 on embracing studlyCaps in the context of PHP itself. (Note: studlyCaps originated with a OO language, namely Smalltalk, but it is not pervasive in OO land. If you don't believe me, just look at the STL. You won't find any uglyCaps over there.) - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
On Dec 3, 2003, at 5:14 PM, Michael Walter wrote: George Schlossnagle wrote: My vote is on StudlyCaps for class method and attribute names. This is the standard in many OO languages (SmallTalk, C#, Java - as a parenthetical I don't think that SmallTalks adoption of StudlyCaps (one of the first I'm aware of) had anything to do with _ rendering), and while we do not need to mimic other languages, adopting common conventions is a good thing. On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly foobarbaz) and Ruby (mostly foo_bar_baz). To be pedantic, the Python style guide (http://www.python.org/peps/pep-0008.html) specifies class names to be StudlyCaps and method names to be either underscore-delimited or StudlyCaps, at the authors leisure. Of course, PHP is not Python. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Andi, I'm -1 too because I want PHP being consistently have _ in method/function names. (Another reason is to see the difference between core and user code as Ulf pointed out). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
Georg Richter wrote: How about an additional configure option --with-studly-caps (disabled by default) and defining some additional aliases? Ouch... That would render code written from one place unusable on another server.. Oliver -- GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K w--(---) !O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI D+ G++ e+++ h(*) r y+(?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] StudlyCaps
3rd using different naming conventions in procedural and oo code seems to be a pro from my point of view, too. What is the perceived advantage here? Do you type - and immediately forgot what follows that? This really is no argument in the context of PHP (no implicit binding of functions) or Java (no global functions). - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
