Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Zitat von Paul M. Jones : Hi Internals, After a couple of years of incubation, I am happy to offer a second version of this RFC: https://wiki.php.net/rfc/request_response It proposes an object-oriented approach around request and response functionality already existing in PHP, in order to reduce the global-state problems that come with superglobals and the various response-related functions. I like this proposal a lot, since it provides a clear, concise interface to these commonly uses, yet inconveniant to use, existing functions and variables without having to always use a full-featured userland library. Speaking of interfaces: since you suggest using decoration and composition over extension for ServerResponse, I am missing a ServerResponseInterface, so that you can easily typehint such userland decorators. -- Jan Schneider The Horde Project https://www.horde.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: patch for imap bug 77153
Zitat von Bishop Bettini : On Wed, Nov 21, 2018 at 7:27 PM Stanislav Malyshev wrote: Hi! > Anyhow, this is water under the bridge now, and I think we should issue > a call for maintainership[4] for ext/imap as soon as possible, since > this is not the only issue[5] of this unmaintained[6] extension. Pierre is listed as maintainer. But given that he is for deprecating it, I guess we try to find somebody who is willing to revive it (not likely) and failing that (likely) go the deprecation route probably... Given how many references to it I see on github though, it's not the best outcome. I'd like to take this one, too. RoundCube may roll its own, but I know the popular Horde IMP uses this extensively. Horde isn't using ext/imap since ages, but has developed a PHP-only IMAP library long ago, that's being used by many other OSS projects too. I suspect that the extension's going to have the performance one would desire when dealing with giant mailboxes, but c-client is hard to deal with. I've had experience with c-client for a while (stretching back to Pine days), and yet still would like to roadmap our way to a modern implementation. bishop -- Jan Schneider The Horde Project https://www.horde.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating ldap_sort
Zitat von Andreas Heigl : Hi Anatol. Côme already replied to the technical aspects of what we are trying to do. Am 25.06.15 um 17:56 schrieb Anatol Belski: Hi Andreas, -Original Message- From: Andreas Heigl [mailto:andr...@heigl.org] Sent: Wednesday, June 24, 2015 5:40 PM To: internals@lists.php.net Cc: Côme BERNIGAUD Subject: [PHP-DEV] Deprecating ldap_sort Hi everyone. Côme Bernigaud and myself are currently cleaning up the LDAP-Extension (Well, Côme is doing the hard work and I'm trying to assist in some way). We would like to bring it in line with a more recent version of the OpenLDAP-lib. Currently the plan is to require OpenLDAP 2.4 as the minimum version to build ext/ldap against. This is on a very good way [1]. But in said OpenLDAP-library the ldap_sort-function already has been marked as deprecated [2]. Therefore we'd like to at least mark PHPs ldap_sort function as deprecated also. The current rewrite will make it possible to later use the server-sided sort functionality so there will be only limited need for the current (client sided) ldap_sort function. As it's a BC-break to remove the ldap_sort function will we have to setup an RFC for that? Or is it a plain "mark it deprecated in PHP7 and throw it away in PHP8" kind of decission? And will it be possible to get that marked deprecated in 7 at all? I've a few questions to this. Can it be implemented with non deprecated symbols? Or maybe, can the server side sort not be done with the same function, as it's probably the same job? Or it will be really not required? Any info about the plans on the openldap side to remove the deprecated symbols (AFAIR those are kept already for years)? We're currently don't know, how wide this function is used and how much it would break. In general, deprecating it if there's a strong reason, could be sufficient. If there's a small possibility to keep this function, we should use it. Fe maybe it could kept and enabled with a configure option, that way it'll be still usable. I might have not expressed myself correctly about the deprecated thingy. I was actually refering to whether it would be possible to raise an E_DEPRECATED for calling ldap_sort. If we could bring that into PHP7.0 we would be able to remove it from PHP7.1 and get a clean codebase without any functions marked as deprecated in the underlying lib. If we'd have to wait for PHP7.1 for the E_DEPRECATED that would mean we can remove the deprecated function_calls at the earliest in PHP7.2. That's a long timescale ;) Any feedback from the ldap users were appreciated here, as well. I don't use it ;) I've checked phpLdapAdmin (not used), GOsa (not used) and Zend\Ldap (sadly used, but I can rewrite that part) but that are just three libs out there out of so many self-written scripts FWIW Net_LDAP and its successors Net_LDAP2 and Horde_Ldap don't use ldap_sort anymore since 2006 either. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Streams BC break unfixed since 5.6.5
Hello, now that RFCing has settled down a bit, and things should get back to more development and less politics, can someone please take a look at this regression: https://bugs.php.net/bug.php?id=68948 that has a PR here: https://github.com/php/php-src/pull/1153 This BC breaking regression is breaking real world applications since two 5.5 and 5.6 releases (http://3v4l.org/YJRWQ) and the fix is ready to merge, at least to the master branch. Thanks for looking into this, Jan. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC][VOTE][RESTART] Strict Argument Count On Function Calls
Zitat von Marcio Almada : Hi, As promised, the "Strict Argument Count" RFC vote was restarted: RFC: https://wiki.php.net/rfc/strict_argcount PR: https://github.com/php/php-src/pull/1108 There was no need to update the BC break section. The only minor change was the addition of the following section: https://wiki.php.net/rfc/strict_argcount#about_callbacks_invoke_and_dynamic_calls The voting will close in exactly 14 days counting from now. This is the discussion summary so far http://markmail.org/thread/ol5s2vhw35ac2px3 Acknowledgments to Bob Weinand for offering a practical solution that will help many in case the RFC passes. Thanks, Márcio I voted no because I see the "Flexible" Interface Implementations mentioned in the RFC a valid and common use case, and the proposed solutions not suitable. You probably haven't found those during real code tests because it's commonly used to "migrate" or "extend" APIs. You add a new optional parameter to both the caller and callee of an API, with defensive coding so that both still work if that parameter is not available. This is done to not require new dependency versions. But you won't find those cases if you test complete software stacks, because in the most current version of both modules you will have the new parameter available. Beside that, your testing sample was pretty small. Jan. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Zitat von Anatol Belski : Hi Stas, On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote: Hi! And at list this one living native PHP implementation https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and more library links in the older thread link above). This is part of Horde with 9 listed dependencies and 9 suggested ones, and probably also sub-dependencies. It is much less convenient than having imap right here when you run PHP. And looks like on top of that it lists PHP 7 as not supported. I'm sure there are other imap implementations, but I wouldn't be that quick in throwing out one that a lot of people may use. -- Stas Malyshev smalys...@gmail.com Horde is being developed by a some ISP, so it's mostlikely gonna support PHP7, even if not already. But this is actually what one can say regarding PHP7 compatibility with any scripts at the current stage. FWIW Horde is an open source project and not developed by any ISP. Furthermore we're actively testing against PHP 7 and already detected (and reported) a few bugs an regressions in master. Not that this matters for this discussion, just for completeness. For security tickets - there are still some on mitre, NVD and others. The point with ext/imap being available "now and here" instead of the userland implementation is of course good. However removing it has the same reasons like f.e. removing ext/regex or Apache 1.x SAPI. Letting it be there, unmaintained, is kinda of a black hole. And every day it grows. That's why my point is rather - link to some userland implementation instead of shipping "worky" stuff in the unknown security state. Same actually for mcrypt. Probably the same motivation can be attributed to the unavailability of libc-client and mcrypt in RHEL6. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7dev Vagrant box
Zitat von Ferenc Kovacs : On Thu, Jan 29, 2015 at 11:03 AM, Jan Schneider wrote: _Zitat von Ferenc Kovacs :_ _On Thu, Jan 29, 2015 at 9:57 AM, Jan Schneider wrote:_ _Zitat von Rasmus Lerdorf :_ _As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/_rasmus/boxes/php7dev_ _The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus__ __The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below.__ _ _ _ _ __what version of vagrant are you using? (you can check via vagrant --version)__ __adding boxes like that (username/boxname format instead of using the full url for the box) is only supported since vagrant 1.5__ __if you don't wanna upgrade you could try something like__ __vagrant box add https://atlas.hashicorp.com/rasmus/boxes/php7dev __ __vagrant init php7dev__ __but probably easier to just upgrade__ _ _ __--__ __Ferenc Kovács @Tyr43l - http://tyrael.hu__ _It's indeed 1.4, but that doesn't work with the full URL either. Upgrading is the way to go._ _agree, but out of curiosity, could you try the following with 1.4?:_ _vagrant box add "rasmus/php7dev" https://vagrantcloud.com/rasmus/boxes/php7dev/versions/0.0.2/providers/virtualbox.box --provider virtualbox_ _-- _ _Ferenc Kovács @Tyr43l - http://tyrael.hu_ Too late, I already upgraded. But 1.4.x is the version shipped with recent Ubunutu (and thus probably recent Debian), so you can easily test it there. - Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject
Re: [PHP-DEV] php7dev Vagrant box
Zitat von Ferenc Kovacs : On Thu, Jan 29, 2015 at 9:57 AM, Jan Schneider wrote: Zitat von Rasmus Lerdorf : As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/_rasmus/boxes/php7dev_ _The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus_ _The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below._ _what version of vagrant are you using? (you can check via vagrant --version)_ _adding boxes like that (username/boxname format instead of using the full url for the box) is only supported since vagrant 1.5_ _if you don't wanna upgrade you could try something like_ _vagrant box add https://atlas.hashicorp.com/rasmus/boxes/php7dev _ _vagrant init php7dev_ _but probably easier to just upgrade_ _-- _ _Ferenc Kovács @Tyr43l - http://tyrael.hu_ It's indeed 1.4, but that doesn't work with the full URL either. Upgrading is the way to go. --------- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject
Re: [PHP-DEV] php7dev Vagrant box
Zitat von Rasmus Lerdorf : As a follow-up to my PHP7 Homework post last week, here is a bit of spoon-feeding for all you lurkers on this list. https://atlas.hashicorp.com/rasmus/boxes/php7dev The description there should be fairly self-explanatory. If you have a computer running Linux, OSX or Windows and about 4G of disk space, heck install it on a $5 USB stick, then you don't have any excuses. It will takes less than 15 minutes of your time, and most of that is waiting for the download. Please use it to install your own applications or whatever random PHP applications out there you can find and help us track down issues. We have been plagued by bugs being found after initial releases because not enough people helped test in the past. Let's try to get ahead of them this time. -Rasmus The first command from your instructions there get me: $ vagrant box add rasmus/php7dev This command was not invoked properly. The help for this command is available below. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
Zitat von Lester Caine : On 21/11/14 11:31, Rowan Collins wrote: I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! To reply with a broken record of my own: E_STRICT does not indicate code that will break in a future version. Hiding E_STRICT notices will have absolutely no detrimental effect on your code, now or in the future. It is up to you if you want to improve the code by following the hints, or ignore them because the code works fine. So, no this is not at all similar to the "problem" of E_STRICT, because that problem is not real. So everything that currently requires e_strict disabled to allow it to work will continue to work in PHP7? Including the parts that have now been marked for removal since being deprecated since PHP5.3? You confuse E_STRICT with E_DEPRECATED. Without raising E_DEPRECATED in an earlier minor PHP release, a feature/construct cannot be removed from PHP. In practice ... NO the code does not work fine UNLESS you ensure that all of the infrastructure is still using old versions of libraries. And even then we still get white screen responses with changes of PHP versions. My point is that on one hand people are COMPLAINING that code such as PHP 4 Constructors is not being updated and then ALSO claiming that we don't need to ... PLEASE can we have a level playing field to code to! I still don't get get what problem this RFC is actually going to solve? I don't see a problem. Yes, PHP4 constructors are are old and should no longer be used. But there is no problem still supporting them. Raise an E_DEPRECATED for those, and be done with it. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Zitat von Pierre Joye : On Thu, Oct 27, 2011 at 12:00 PM, Jan Schneider wrote: I'm going to check with our Jenkins guru, but I'm wondering how such a VM should look like. Should it contain a complete Jenkins instance, or just a checkout of the Horde packages that you would run from your own Jenkins server(s)? It will be no different to what you have now to run the tests locally. All we need is a result set (json) that will be pushed in our servers and displayed, alerts will be sent on errors, etc. Are you online somewhere for a chat? Each and every day on #horde @ freenode. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Zitat von Pierre Joye : hi Jan! On Wed, Oct 26, 2011 at 11:16 AM, Jan Schneider wrote: On Tue, Oct 25, 2011 at 12:13 PM, Ferenc Kovacs wrote: from a quick look on their setup, they only have one node, and they are using the global php binary, so no, they are only testing one php version, and I don't think that it would be the snapshot. but that would be cool. :) Ferenc is right, this is testing against the distro's latest version. It is sadly not very useful for us, while being informative. To know that something went wrong when a release is already out is too late, let alone when the distros updated their package :) Sure, this was just to showcase the number of tests that we already run continuously to find regressions in *our* snapshots. It is a must and it is what we need to do. We don't have the resources to run such a node on our own. The idea was to provide the test suite of the most recent package releases for such a snaphot testing machine (run by the php group?) Do you have some time to setup the tests script in a VM? Then we will use what we have already to run php's snapshot and RCs. We will share VMs for 2-3 projects. I'm going to check with our Jenkins guru, but I'm wondering how such a VM should look like. Should it contain a complete Jenkins instance, or just a checkout of the Horde packages that you would run from your own Jenkins server(s)? Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Zitat von Pierre Joye : On Tue, Oct 25, 2011 at 12:13 PM, Ferenc Kovacs wrote: from a quick look on their setup, they only have one node, and they are using the global php binary, so no, they are only testing one php version, and I don't think that it would be the snapshot. but that would be cool. :) Ferenc is right, this is testing against the distro's latest version. It is a must and it is what we need to do. We don't have the resources to run such a node on our own. The idea was to provide the test suite of the most recent package releases for such a snaphot testing machine (run by the php group?) Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Zitat von Ferenc Kovacs : On Thu, Oct 6, 2011 at 2:49 PM, Jan Schneider wrote: Zitat von Pierre Joye : On Fri, Sep 23, 2011 at 12:23 PM, Rasmus Lerdorf wrote: On 09/23/2011 12:17 PM, Pierre Joye wrote: We do 2) already (while we are working on increasing the amount of apps and frameworks being tested), as I was asking to revert this patch between 5.3.7 and 5.3.8 back then pointing to our tests results and numerous reports. The problem was not in the QA but in the decision process. QA should have a kind of veto power in this case to avoid arguing and still have BC breaks landing in stable releases. Well, 5.3.7 - 5.3.8 wasn't really the problem. That release was rushed to fix my crypt screwup. This should have been caught in the 5.3.6 - 5.3.7 testing which lasted much longer than the short window to 5.3.8. Right, also reported back then with the same success ;) Anyway, that's past, the BC break has been fixed and we are working to get these apps&frameworks tests result as part of our release process (symfony and doctrine are on the road, must see with zf if we can share resources as they do it anyway internally). http://ci.horde.org/ If using the released versions, that would add another 5000 tests. http://www.downforeveryoneorjustme.com/ci.horde.org "It's not just you! http://ci.horde.org looks down from here." FWIW it seems to be more stable now since upgrading to a newer Jenkins version. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Zitat von Pierre Joye : On Fri, Sep 23, 2011 at 12:23 PM, Rasmus Lerdorf wrote: On 09/23/2011 12:17 PM, Pierre Joye wrote: We do 2) already (while we are working on increasing the amount of apps and frameworks being tested), as I was asking to revert this patch between 5.3.7 and 5.3.8 back then pointing to our tests results and numerous reports. The problem was not in the QA but in the decision process. QA should have a kind of veto power in this case to avoid arguing and still have BC breaks landing in stable releases. Well, 5.3.7 - 5.3.8 wasn't really the problem. That release was rushed to fix my crypt screwup. This should have been caught in the 5.3.6 - 5.3.7 testing which lasted much longer than the short window to 5.3.8. Right, also reported back then with the same success ;) Anyway, that's past, the BC break has been fixed and we are working to get these apps&frameworks tests result as part of our release process (symfony and doctrine are on the road, must see with zf if we can share resources as they do it anyway internally). http://ci.horde.org/ If using the released versions, that would add another 5000 tests. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Zitat von Pierre Joye : On Mon, Jul 11, 2011 at 10:15 AM, Jan Schneider wrote: Zitat von Ferenc Kovacs : On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), float&co as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1 not too many though. Try that for String and it reveals a different picture. Horde 3 used that too FWIW. Jan. Even the php5 versions of Horde? That's rather bad given the so strong and loud warnings we gave about using common names w/o namespace, by the time of the date problem. No, of course not. That's why I didn't voice an opinion, I just found it worth mentioning. Horde 3 users can stick with PHP 5.3, while Horde 4 users are not affected at all. It's still used in a lot of other code though, see the github search. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))
Zitat von Ferenc Kovacs : On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote: hi, As I could agree on this fact, I can't find any existing project having int(eger), float&co as class, namespaced or not. Do you have any example at hand? Cheers, https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1 not too many though. Try that for String and it reveals a different picture. Horde 3 used that too FWIW. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach() for strings
Zitat von Larry Garfield :
On 06/20/2011 10:25 AM, John Crenshaw wrote:
Doing this with an explicit iterator object is a fine idea. The
syntax becomes something like:
foreach(new TextIterator($s, 'UTF8') as $pos=>$c)
{
...
}
On the other hand, I think that trying to support iteration without
using an iterator object to mediate would be a disaster, and I'm
opposed to doing something like that because:
1. The code just looks wrong. PHP developers are generally
insulated from the char-arrayness of strings. In addition, since
PHP isn't typesafe, the code becomes highly ambiguous. Is the code
iterating an array, or a string? It is very hard to tell just by
looking. It may be convenient to write, but it's certainly not
convenient to read or maintain later. On the other hand, with a
mediating iterator object, the intent becomes obvious, and the code
is highly readable.
2. The odds of iterating any given string are slim at best.
Supporting current, key, next, etc. would require the string object
internally to get bloated with additional unnecessary data that is
almost never used. This bloat isn't a single int either. For
optimal performance it would need to consist of no less than two
size_t (char position and binary position), and one encoding
indicator.
3. Iteration cannot work without knowing which encoding to use for
the string. Is it UTF8? UTF16? UTF7? Binary or some single byte
encoding? Some other exotic wide encoding? Without an iterator
object in the middle, there is no way to specify this encoding.
Always treating this as binary would also be a mistake, since this
is almost certainly never actually the correct behavior, even
though it may often appear to behave correctly with simple inputs.
4. I've had simple mistakes caught numerous times when foreach
complains about getting a scalar rather than an array. So far, it
has been exactly right every time. Allowing strings to be iterated
would, in the name of convenience, increase the probability of
stupid mistakes evading detection. Even worse, the code itself
would look logically correct until the developer finally realizes
that they have a string and not an array. Errors like this are
probably far more common in most projects than the need to iterate
a string, so making this change hurts debugging in the common case,
for the sake of syntactic sugar in the rare case. Not a good trade.
John Crenshaw
Priacta, Inc.
I would echo John's statements here. foreach() directly iterating a
string is going to make my life substantially harder. I work in
array-heavy systems, and "bad first argument for foreach()" is
already a hard enough error to track down. It means "somewhere,
somehow, you put a string where you meant to put an array. GLWT."
Adding automatic string iteration would take away even that error
message and leave me with no way to figure out why my code is
randomly misbehaving. Just looking at the code, I would have no way
of knowing that such a bug lurks within. That's the downside of a
weakly typed but still typed language.
And if that very same string that's supposed to be an array is
processed using the $var[$n] syntax nowadays is any different? It's
not, you won't get an error message for that either, and it's the same
amount of work to track this down. Granted, making PHP behaving the
same in foreach gives you one more place to track down such errors,
but making it easier to track down developer errors is not anything
that should keep PHP from adding new features.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ChangeLog
Zitat von Pierre Joye : 2010/5/29 Johannes Schlüter : Hey, On Fri, 2010-05-28 at 23:50 +0200, Pierre Joye wrote: I'd to add that unless we add everything in the NEWS file, the ChangeLog remains the only way to have a list of all changes (without doing manually). Having the file is absolutely fine with me, while I can fulfill my needs with svn annotate and svn log. But if we ship it, it should be correct and at least since 5.2.0 we ship a wrong (not updated) file. And that I consider bad. So I ask somebody to either remove it or make sure it's updated (automatically or by adding instructions to README.RELEASE_PROCESS) in all places. Maybe simply do it at release time? Having the changelog updated automatically used to be a really useful thing, because there also existed a mailing list that sent daily (or weekly?) diffs to the changelog file. This way you could easily follow development of PHP without having to subscribe to the commits mailing list. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Turkish/Azeri locale support
Zitat von Adam Harvey : Well, I'm going to assume that people have had whatever say they were going to. It seems that we have three options, so let's put it to a vote. +1 for option 1. Unless we can have some aliases to fix the problem with some PHP functions being documented non-all-lower-case, like the GD functions mentioned earlier in the thread. In that case: +1 for 2. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
Zitat von Johannes Schlüter : On Tue, 2010-03-16 at 22:13 +0100, Lukas Kahwe Smith wrote: On 16.03.2010, at 16:58, Derick Rethans wrote: > Before we add features, they need to be discussed whether we want to > have them. As version name for it I would like to use "trunk-dev" (and > not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. > Right now, there are the following features that I can see we should > think about: Since we do not know the name of the next version yet, maybe its best to base the name on what version it will have as a predecessor and add support for this in version_compare()? Something like "5.3post". Ok this isnt a good suggestion, but I hope you get what I am suggesting. We need a version number which can be represented as a numeric value like #define PHP_VERSION_ID 50303 to help extension authors; as said on IRC 5.4 is the only sane choice there. We can still increase the number if needed. How to document this is a good question... How about 5.3.99? A lot of projects use this for pre-releases, but it still might make sense. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0alpha2
Zitat von Lukas Kahwe Smith <[EMAIL PROTECTED]>: Windows binaries (optimized for various versions of Windows) are available from the new website dedicated to PHP's windows binaries: http://windows.php.net/downloads.php Looks like the file descriptions are wrong. The non-TS "PHP 5.3.0alpha2 VC9 x86" is labeled as "VC9 build x64." Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] expose PHP version details as constants
Zitat von Jingcheng Zhang <[EMAIL PROTECTED]>: Hello, Is there any chance that dirname(__FILE__) being exposed as a constant, i.e. __DIRNAME__? No. Constants are per request, dirname(__FILE__) is obviously different per file. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
Zitat von Antony Dovgal <[EMAIL PROTECTED]>: 6 reasons why we must to get rid of The Switch ASAP Having maintained a huge Unicode compatible codebase in PHP4 for the last few years, I know which PITA it already is today, having to consider the availability of mbstring and iconv, or dealing with different input, processing, backend, and output charsets. I don't event want to start thinking about adding unicode semantics to that equation. Drop it. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.1RC2 Released
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>: The 2nd release candidate for PHP 5.2.1 is now available for download. The tarballs can be found here: The ming extension doesn't compile at the moment: /home/jan/software/php-5.2.1RC2/ext/ming/ming.c: In function 'getFontOrFontChar': /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:3847: error: 'fontchar_class_entry_ptr' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:3847: error: (Each undeclared identifier is reported only once /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:3847: error: for each function it appears in.) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c: In function 'zm_startup_ming': /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4234: error: 'SWFTEXTFIELD_USEFONT' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4235: error: 'SWFTEXTFIELD_AUTOSIZE' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4255: error: 'SWF_SOUND_NOT_COMPRESSED' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4256: error: 'SWF_SOUND_ADPCM_COMPRESSED' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4257: error: 'SWF_SOUND_MP3_COMPRESSED' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4258: error: 'SWF_SOUND_NOT_COMPRESSED_LE' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4259: error: 'SWF_SOUND_NELLY_COMPRESSED' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4260: error: 'SWF_SOUND_5KHZ' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4261: error: 'SWF_SOUND_11KHZ' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4262: error: 'SWF_SOUND_22KHZ' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4263: error: 'SWF_SOUND_44KHZ' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4264: error: 'SWF_SOUND_8BITS' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4265: error: 'SWF_SOUND_16BITS' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4266: error: 'SWF_SOUND_MONO' undeclared (first use in this function) /home/jan/software/php-5.2.1RC2/ext/ming/ming.c:4267: error: 'SWF_SOUND_STEREO' undeclared (first use in this function) make: *** [ext/ming/ming.lo] Fehler 1 Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
Zitat von Hans Lellelid <[EMAIL PROTECTED]>: I think there is far more demand for a fast & stable PHP then for syntatic sugar features which seem extremely useful, but in the end prove to carry too much baggage. Nothing has been proven either way.. at least not publicly.. unless I just missed it. I haven't talked to a single developer a large-scale PHP tool, application, etc. that wouldn't switch their trunk to using namespaces tomorrow if they were adopted in the engine. We [in] PHP developers who are building "enterprise" open-source components and frameworks really will use this feature -- and I think we'd all argue that we really need this feature. I hope that namespaces would be more than syntactic sugar -- e.g. providing an import/using keyword that would declare namespace context -- but even if they were only "syntactic sugar" they would at minimum provide a naming standard for PHP packages to avoid collisions. Namespaces certainly got a lot of mention at Int'l PHP Conference (in form of request and, during the panel, applause from audience when mentioned); it was clear that this is a very anticipated PHP6 feature. None of us non-C developers are trying to say we think this should be easy, or trying to otherwise minimize the problems that have been presented in the past or the reasons why it hasn't been implemented so far, but let there be no confusion that this is a really, really important feature for us. I couldn't agree more. There really wasn't an appealing reason to switch to PHP5 too quickly for me, and force the users of our code to do the same. There are a few reasons to switch to 5.2 probably, but that's a different story. But if there wasn't already Unicode support in PHP 6, having namespaces was definitely a good reason to force our user to that version. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request
Zitat von Dmitry Shirokov <[EMAIL PROTECTED]>: Hey guys. What are you thinking about adding this feature: Yes, please, that would be most important shorthand functionality after dereferencing. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RELEASE_1_0_4
Zitat von Derick Rethans <[EMAIL PROTECTED]>: Hello! For some reason all of our code in all repositories in CVS have a tag "RELEASE_1_0_4". Seems to have happened on the 18th, according to the timestamp in the ChangeLog's history: http://cvs.php.net/viewcvs.cgi/php-src/ChangeLog?view=log If you think you've something to do with this, please reply as we'll have to cleanup this tag from many extensions. :I That's pretty easy, isn't it? RELEASE_x_x_x tags are used for PEAR package releases, and the only PEAR release in question is System_Command 1.0.4 on the 20th. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Rasmus statcallpatch with configure option
Zitat von Derick Rethans <[EMAIL PROTECTED]>: On Tue, 14 Sep 2004, Andi Gutmans wrote: a) I will try and send internals@ an updated version of the realpath() cache in the next few days. This should give a lot of bang for the buck because realpath() is probably the suckiest system call in the startup. b) Maybe Wez & Sara can take one more look to double check if there aren't any checks they can possibly save without impairing functionality. c) Create a new version of your patch based on (a) & (b) and make sure we find an accessible place for it with the disclaimer. A good accessible place would be our distribution. It's annoying to have to maintain a patch outside the main tree. There is also no reason why people would just enable this feature by default if they have no clue what they are doing, we can add big nice disclaimers around it. I can see nothing wrong with it, I also don't think this is a nasty hack or a crappy patch. I do not seek to have this patch into PHP 5, you can do your realcache magic there if you want. Why not keeping that patch (and others that might be worth it as well) in the php-src module, but really as a patch, not applied to the default distro? This way it's available at a single point, everyone having a tarball can apply it, and it still won't be available with a simple config option. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src /ext/imap php_imap.c
Zitat von Wez Furlong <[EMAIL PROTECTED]>: On Thu, 12 Aug 2004 16:16:51 -0400, Jon Parise <[EMAIL PROTECTED]> wrote: And what if Jan doesn't know C or feel comfortable writing PHP extension code, for example? Even more reason to stop complaining and wait for someone with the appropriate skill to get home from work and give the problem the investigation it deserves. Just to calm this thread down (the issue is fixed anyway, thanks to everyone involved): no, i don't have enough C skills to fix it myself, and no, I didn't want to complain, I just feared that I didn't make clear with my first message that this was a BC break and that 4.3.9 might be released with this broken behaviour. I even rewrote that message to make it sound less complaining before I sent it. In the end it's all about language nuances that you don't get if you aren't a native speaker. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src /ext/imap php_imap.c
Zitat von Jan Schneider <[EMAIL PROTECTED]>: Ilia Alshanetsky wrote: iliaa Wed Jul 21 17:57:03 2004 EDT Modified files: /php-src/ext/imap php_imap.c Log: Fixed bug #29209 (imap_fetchbody() doesn't check message index). # Initial Patch by tony2001 at phpclub dot net http://cvs.php.net/diff.php/php-src/ext/imap/php_imap.c?r1=1.184&r2=1.185&ty=u This "fix" breaks retrieving message bodies if not using the sequence number in imap_fetchbody() but the UID instead. imap_fetchbody($stream, 1, 1, FT_UID) doesn't work anymore, while imap_fetchbody($stream, imap_msgno($stream, 1), 1) works. Jan. P.S.: this patch has been committed to all branches. Just in case I wasn't clear: this is a showstopper for 4.3.9 and 5.0.1 as it breaks every second application using the imap extension to retrieve messages, including IMP. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src /ext/imap php_imap.c
Ilia Alshanetsky wrote: iliaa Wed Jul 21 17:57:03 2004 EDT Modified files: /php-src/ext/imap php_imap.c Log: Fixed bug #29209 (imap_fetchbody() doesn't check message index). # Initial Patch by tony2001 at phpclub dot net http://cvs.php.net/diff.php/php-src/ext/imap/php_imap.c?r1=1.184&r2=1.185&ty=u This "fix" breaks retrieving message bodies if not using the sequence number in imap_fetchbody() but the UID instead. imap_fetchbody($stream, 1, 1, FT_UID) doesn't work anymore, while imap_fetchbody($stream, imap_msgno($stream, 1), 1) works. Jan. P.S.: this patch has been committed to all branches. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: protected/private access and var_dump/print_r
Zitat von Andi Gutmans <[EMAIL PROTECTED]>: I'm OK with adding it to print_r() too if no one has any serious objections. Perhaps only for members explicitely declared public, as opposed to var-style properties. At 12:04 PM 5/20/2004 +0200, Derick Rethans wrote: On Thu, 20 May 2004, Andi Gutmans wrote: > Fine with me. I'm not sure printing public is a bad idea. How many ppl > actually use this in their application for purposes other than debugging? Well, print_r doesn't print it either; so IMO if we add public here, we need to do that for print_r too. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Interface inheritance
Zitat von Zeev Suraski <[EMAIL PROTECTED]>: At 13:01 19/04/2004, Christian Schneider wrote: Zeev Suraski wrote: Any method that implements (directly or indirectly) an interface method or an abstract method, will have implementation checks fully enforced, with an E_COMPILE_ERROR emitted in case of an error. Excuse my ignorance: What is defined as fully implementing the interface? I guess all methods have to be implemented with all the parameters having the same type if specified, right? What about extending the parameter set, especially with default values? E.g. is foo(A $a, $newparam = 'false) valid for foo(A $a)? This is valid. As long as you *can* call the function using the same prototype as the one in the interface, it's considered to be compatible. You can extend it using default values. +1 from a user's perspective, that is pro fatal errors on interfaces and abstract methods but not on regular methods. That's the best balance on keeping BC and introducing useful OO features. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: reproduce script (Re: [PHP-DEV] No static method callbacks anmore?)
Zitat von Andi Gutmans <[EMAIL PROTECTED]>: Should be fixed now. Thanks for the reproducing test case. Yeah, works fine now, thanks. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] No static method callbacks anmore?
Zitat von Andi Gutmans <[EMAIL PROTECTED]>:
Can you do a reverse apply of the following diff and let me know if it
fixes the problem?
http://cvs.php.net/diff.php/ZendEngine2/zend_execute_API.c?r1=1.274&r2=1.275&ty=u
No, it doesn't.
At 05:04 PM 3/15/2004 +0100, Jan Schneider wrote:
Hi,
before reporting a bug, I want to make sure that this is no intentional
change. Are static methods no longer supported as callbacks?
preg_replace_callback('/some pattern/', array('MyClass', 'Method'),
$subject)
raises a warning atm:
Unable to call custom replacement function in ...
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - Neue Wege des Lernens
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] No static method callbacks anmore?
Hi,
before reporting a bug, I want to make sure that this is no intentional
change. Are static methods no longer supported as callbacks?
preg_replace_callback('/some pattern/', array('MyClass', 'Method'),
$subject)
raises a warning atm:
Unable to call custom replacement function in ...
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - Neue Wege des Lernens
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC1 of RC1
Zitat von Andi Gutmans <[EMAIL PROTECTED]>: I fixed get_object_vars() a couple of days ago. Can you check if this still occurs? No, that seems to have fixed it, thanks! At 01:52 PM 3/15/2004 +0100, Jan Schneider wrote: Zitat von Andi Gutmans <[EMAIL PROTECTED]>: I will roll RC1 on the 17th so if there are "serious" show stoppers speak up. Dunno what you consider "serious", but bug 2 http://bugs.php.net/bug.php?id=2 is on the ze2 level. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC1 of RC1
Zitat von Andi Gutmans <[EMAIL PROTECTED]>: I will roll RC1 on the 17th so if there are "serious" show stoppers speak up. Dunno what you consider "serious", but bug 2 http://bugs.php.net/bug.php?id=2 is on the ze2 level. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parse error in parsedate.y
Zitat von Derick Rethans <[EMAIL PROTECTED]>: On Tue, 2 Mar 2004, Edin Kadribasic wrote: Same problem on win32 snap box which used to work fine. bison version is 1.75. Should be fixed in CVS now. Yeah, works again, thanks. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Parse error in parsedate.y
Zitat von Jan Lehnardt <[EMAIL PROTECTED]>: Hi Jan, On 2 Mar 2004, at 12:25, Jan Schneider wrote: bison -y /home/jan/cvs/php5/ext/standard/parsedate.y -o /home/jan/cvs/php5/ext/standard/parsedate.c /home/jan/cvs/php5/ext/standard/parsedate.y:389.12: parse error, unexpected ":", expecting ";" or "|" make: *** [/home/jan/cvs/php5/ext/standard/parsedate.c] Fehler 1 Which version of bison are you running? 1.28 works fine here. 1.75 Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Parse error in parsedate.y
bison -y /home/jan/cvs/php5/ext/standard/parsedate.y -o /home/jan/cvs/php5/ext/standard/parsedate.c /home/jan/cvs/php5/ext/standard/parsedate.y:389.12: parse error, unexpected ":", expecting ";" or "|" make: *** [/home/jan/cvs/php5/ext/standard/parsedate.c] Fehler 1 Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SimpleXML Docs
Zitat von Ken Tossell <[EMAIL PROTECTED]>: Hi Internals, I've just committed a new documentation module for SimpleXML, which should show up on php.net sometime. It's available at http://php.kennyt.com/newdocs/?q=ref.simplexml -- if you see any major errors (and there are some, I'm sure), please point them out. The 2nd example uses the undefined $movies variable, should probably be $xml->movie. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] convert_to_writable_*
Zitat von Andi Gutmans <[EMAIL PROTECTED]>: > Any idea who added the following macros? Zeev in version 1.19: Tue Apr 18 18:23:28 2000 Add convert_to_writable_*_ex() macros (unused at this time) :-) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Rasmus Lerdorf <[EMAIL PROTECTED]>: > On Sat, 13 Dec 2003, Jan Schneider wrote: > > Maybe. Due to PHP lacking byte stream functions, working with str* is > the > > only solution atm. > > And my contention is that there is no way to do this right now. If you > rely on a str*() function to do this your application is broken since you > cannot reasonably expect a character to always be 8 bits wide. With the current implemention and assuming that mbstring overloading is turned off, I can. This not documentated, but I'd still consider a change of this behaviour an huge bc break. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Rasmus Lerdorf <[EMAIL PROTECTED]>: > On Sat, 13 Dec 2003, Jan Schneider wrote: > > I have to agree. While in the past it helped mb users to turn on > overloading > > if they wanted to use our framework, it will now break it. This is > because > > we now explicitely use the str*() function for byte-wise string > > manipulation and their mb_*() equivalents for character-wise > manipulation. > > This is the only way to predict the results, the magic that is done by > > overloading or transparent charset conversion is not suitable for real > > production environments. > > Using str*() functions for octet manipulation is fundamentally wrong. > str*() functions by definition work on character boundaries. If we need > to operate on byte boundaries we need to introduce a set of mem*() > functions. Maybe. Due to PHP lacking byte stream functions, working with str* is the only solution atm. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Derick Rethans <[EMAIL PROTECTED]>: > On Sat, 13 Dec 2003, Moriyoshi Koizumi wrote: > > > Overloading is evil, because functions like substr() are often > > used to splice a certain length of octets byte-wise while mb_substr() > > treats the sequence of octets on a character-basis. And overloading > > cannot be turned on in scripts, this prevents us from writing portable > > scripts. There're virtually no cleaner way to do the tasks elegantly. > > I also think overloading is evil, w've seen before what the problems can > be because of difference between an overloaded and a non-overloaded > version. It is however perfectly possible to tune this behavior in the > php.ini file; not sure if we want that though. I guess it depends on your pov. If you want to write portable scripts, relying on overloading or even special php.ini tuning is a nightmare. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>: > > The cool thing that mbstring provides is transparent overloading of > > some > > of the common string manipulation functions. This means that at least > > for > > a subset of applications, even though they may not have been written > > with > > multibyte support in mind, they may in fact work perfectly in a > > multibyte > > environment with mbstring enabled and overloading turned on. > > Overloading is evil, because functions like substr() are often > used to splice a certain length of octets byte-wise while mb_substr() > treats the sequence of octets on a character-basis. And overloading > cannot be turned on in scripts, this prevents us from writing portable > scripts. There're virtually no cleaner way to do the tasks elegantly. I have to agree. While in the past it helped mb users to turn on overloading if they wanted to use our framework, it will now break it. This is because we now explicitely use the str*() function for byte-wise string manipulation and their mb_*() equivalents for character-wise manipulation. This is the only way to predict the results, the magic that is done by overloading or transparent charset conversion is not suitable for real production environments. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>: > On December 12, 2003 05:38 pm, Moriyoshi Koizumi wrote: > > And I don't think fgetcsv() is an exception, since htmlentities() can > > be referred to as an example that is placed in core and > > supports multibyte strings. As I mentioned, purging that kind of > > functionality into the mbstring extension doesn't solve the problem > > in practice by any means. > > htmlentities() is a rather special function it handles not only multibyte > but > a whole lot of diffrent & unusual things. I do not think you can fairly > compare it to fgetcsv(). We have a multibyte extension for people who > need > that functionality, why force it on everyone else? > > > >> 2) IMO speed is not a key factor here. People rather wants > > >> trust-worthy behaviour. > > > > > > When it's a few percent and the changes offer significant > improvements > > > yes, > > > but when were are talking about a performance loss of 250-300% or > more > > > then > > > performance must become a consideration as well. > > > > If there are virtually no ways to improve it, it'd be natural to me > > we dismiss the issue. > > Why does a vast majority of users have to endure degredation in > performance > for functionality that are needed by a few? It's as simple as that. Same > argument applies to basename(). Just a general note on this discussion becoming sort of a "meta"-topic: >From a PHP developers POV, complete charset support should be a key technology for ZE and the standard extensions, as is now XML for PHP5 as a whole. While the comparison might be a bit strange, it even reminds on the relation of these two: The "standard" encoding for XML data is a multibyte charset. But the real problem is, that it's *really* hard for developers outside of the "multibyte" world to understand the ins and outs of these charsets and how to handle them correctly. It was a PITA to make the whole Horde framework charset independent without knowing anything on mb charsets and their support in php. I did this due to popular demand, because there are a *lot* of people using/needing mb charsets. It would be great if others developers wouldn't have to take this steep road, because php would support these out of the box. While writing this message, Rasmus got my point in fewer words. ;-) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Zitat von Edin Kadribasic <[EMAIL PROTECTED]>: > On Thursday 27 November 2003 11:47, Jan Schneider wrote: > [snip] > > behaviour/notification and not working on-the-fly-generation of > stdClass > > objects. It's not that much of a problem for us as we will release new > > What exactly is the problem with stdClass? We have a lot of code overhere > that > rely on stdClass behaiving as it did in php4. Actually I'm not sure if this problem still exists, but I found that checking our commits related to ZE2 fixes. Creating objects on the fly didn't work or at least raised a warning/error. I changed code like: $not_existing_object->foo = "bar"; to: $not_existing_object = new stdClass(); $not_existing_object->foo = "bar"; Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Zitat von Andi Gutmans <[EMAIL PROTECTED]>: > Hi guys, > > Now that we're at a very advanced stage and the code freeze is coming up, > I > think it'd be a good idea to start running some PHP 4 applications on PHP > 5 > and see how easy things go. I'm sure we'll bump into some issues and many > of them might be solvable (using the already existing compatibility mode > for object cloning or by other means). > > If anyone here has time or has already tried running some popular PHP > packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to hear > about your experience and especially the problems. Horde et al suffered from new reserved words, the known return-non-variables-by-reference-problem, the changed array_merge() behaviour/notification and not working on-the-fly-generation of stdClass objects. It's not that much of a problem for us as we will release new major versions near to the PHP 5 release, that will be tested with PHP HEAD. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] EXTRA_VERSION
... has not yet been reset to -dev in configure.in Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] header() behaviour
Zitat von Tal Peer <[EMAIL PROTECTED]>: > On Tue, 28 Oct 2003, Gareth Ardron wrote: > > > I can't figure out if this is desired or not, if it's not, I'll happily > > draft up a patch to alter the behaviour - I just want to make sure > > before I do. > > Why should header() start parsing its argument? its only job is to add > its > argument to the HTTP headers, nothing more, nothing less. > It's the browser job to parse the & entity into the character '&'. Beside that, HTTP headers have nothing to do with XHTML, so this behaviour is absolutely correct. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>: > On October 7, 2003 08:45 pm, Jan Schneider wrote: > > I never said that the current behaviour is in any way consistent. But > which > > behaviour the more logical one is, is debateable. Many languages > support > > context dependant implicit casting, and PHP even says so explicitely in > the > > manual. Why should this now be incorrect, not logical or not "proper"? > > Incosistent behaviour is a problem, whether it is a serious problem or a > trivial one depends on a situation, however it does not change the fact > it is Agreed. But we are talking about PHP, not a nice, clean programming language. While PHP is indeed nice, it was never and still isn't very clean, for historical reasons. To make it cleaner and fix inconsistencies is a great goal if done in a new major or a single dot version. PHP 5 would be a good possibility for such changes but even then have many suggestions been dropped for bc reasons. > a problem. IMO when a function expects an array it should error out when > the > argument it recieves is not array, with a possible exception of object's > who > in ZE1 are nearly identical to arrays. Further more there is already an > fairly large number of functions of a similar function that operate in a > similar manner. It only makes sense to fix the one or two that do not. Heck, we are talking about a *bugfix* release. May I quote you're own announce message? "This release candidate contains only bug fixes, so it should be quite stable." What bug is this change to fix? There is no bug, only a inconsistency that worked perfectly for ages. And while it may be stable is makes existing apps instable. I can't believe we have to argue about this. You are going to "break" (or at least annoy user of) at least two of the biggest and mostly used PHP projects that happen to have E_ALL enabled by default. Will *you* personally subscribe to [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] and answer every single soul complaining why after upgrading to a bugfix release of PHP they are now flooded by PHP notices of code that worked flawlessly for months? You argue that this already is an E_WARNING in PHP 5 and making it an E_NOTICE in 4.3.4 would teach the users (will it? it will only teach developers) to fix unlogical code. You shouldn't call it a bugfix release then but an "educational" release. Or call it a pre-release version of PHP 5 to show users what will be completely broken if they upgrade to PHP 5. So can now someone *please* revert this in the PHP_4_3 branch, or start a voting about this, but let us stop this needless discussion. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>: >$a = null; > sort($a); > ?> > > Majority (if not all) array function, will error out when they encounter > a > variable that is not array when an array argument is expected. If > anything > this patch add consistency that helps to make code clearer. Heck, Is > suspect > a far number of people will be able to find bugs in their code because > they > will now be warned that a function is getting a string/null/etc... > instead > silently accepting any argument. I never said that the current behaviour is in any way consistent. But which behaviour the more logical one is, is debateable. Many languages support context dependant implicit casting, and PHP even says so explicitely in the manual. Why should this now be incorrect, not logical or not "proper"? You can safely argue the opposite, namely that no array function should raise a warning but instead cast the value to an array. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>: > Perhaps, if PEAR developers wrote proper code & did not rely upon > unsupported > & undocumented features we would not have this problem. While they do, > these > problems will occur. If you do not write proper code, either don't turn > on > warnings & notices (that supposed to help you write proper code) or take > the > time to fix the problem. This by no means is a problem in PHP. As Stefan pointed out with his link to the PHP manual, this acutally *is* documented, because it's an implicit cast from a simple type to an array. >From the manual: For any of the types: integer, float, string, boolean and resource, if you convert a value to an array, you get an array with one element (with index 0), which is the scalar value you started with. If you convert an object to an array, you get the properties (member variables) of that object as the array's elements. The keys are the member variable names. If you convert a NULL value to an array, you get an empty array. [...] PHP does not require (or support) explicit type definition in variable declaration; a variable's type is determined by the context in which that variable is used. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Jay Smith <[EMAIL PROTECTED]>: > Most of the other array functions are more stringent -- they don't throw > E_NOTICEs, they throw E_WARNINGs. array_intersect(), array_diff() and > array_sum() being the ones that I can think of offhand. This might be true, but the str_* functions for example don't throw anything at all if you pass them a NULL. So we're inconsistent no matter what we do, it's a bogus argument. The point is that the behaviour changes in a minor release an that is A Bad Thing IMO. I'm selfish admittedly, but Horde's default configuration is to report E_ALL and we are indeed writing E_NOTICE-safe code. In the end we will be flooded with complaints on error messages from code that worked flawlessly for months or even years and still does, just because people upgraded to a *bug fix* PHP release. I'm fine with this notice to be added to the PHP_4 and HEAD branch, but PHP_4_3 is the wrong place. > Jan Schneider wrote: > > > Zitat von Jani Taskinen <[EMAIL PROTECTED]>: > > > >> Passing array_merge*() anything else but arrays is undocumented. > >> These functions were meant to be used on arrays and this change > >> (very, VERY minor change, if I may say so) just "fixes" this. > > > > The only case I really care about are NULLs being passed to that > function. > > And we don't throw E_NOTICEs if using NULLs with any type specific > > function AFAIK. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Jani Taskinen <[EMAIL PROTECTED]>: > Passing array_merge*() anything else but arrays is undocumented. > These functions were meant to be used on arrays and this change > (very, VERY minor change, if I may say so) just "fixes" this. The only case I really care about are NULLs being passed to that function. And we don't throw E_NOTICEs if using NULLs with any type specific function AFAIK. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Mike Robinson wrote: Jay Smith wrote: As near as I can tell, leaving it in seems to be the way to go at the moment. Being as they're E_NOTICEs and not full-on E_WARNINGs and the fact that the actual behaviour of the function hasn't changed (except, of course, the E_NOTICEs), it seems to be a good reminder that the undocumented behaviour being relied upon is subject to change. (And will change in 5, for that matter.) I'd imagine that most setups ignore E_NOTICEs, so most people won't even notice. (No pun intended, of course.) Notwithstanding its very unsafe to make such an assumption, the minority of setups affected by this change could still be in the thousands, tens or even hundreds of thousands. IMHO, if the function behaviour hasn't changed, there should be no notice warning about possible future changes. Thats what documentation and announcements are for. Will this be fixed before the 4.3.4 release? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
I *love* it when threads silently die. ;-)
Will this problem actually adressed by anyone or will we again have to
release new versions of our software just because a minor PHP came out or
deal with a huge amount of user complaints?
Zitat von Jan Schneider <[EMAIL PROTECTED]>:
> Zitat von Jay Smith <[EMAIL PROTECTED]>:
>
> > Jan Schneider wrote:
> >
> > >
> > > I generally agree (this is the purpose of E_NOTICE after all), but
> > there
> > > is a subtle difference between what has been fixed and what is broken
> > now.
> > > Passing NULLs to array_merge didn't lead to the borked arrays that
> have
> > > been "fixed" by this patch.
> > >
> >
> > How are the arrays borked? The patch doesn't touch, skip or otherwise
> do
> > anything to any of the parameters, it just does a type check. Am I
> > missing
> > something here? (Which is quite possible...)
>
> Ah, well, I misread the original bug report. With "borked" I meant that
> array_merge(false, array("foo" => "bar")) resulted in array(0 => false,
> "foo" => "bar"). I though this was changed by the patch.
>
> Anyway, array_merge(array("foo" => "bar"), null) was never producing such
> an
> array and should thus not result in an E_NOTICE.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Jay Smith <[EMAIL PROTECTED]>:
> Jan Schneider wrote:
>
> >
> > I generally agree (this is the purpose of E_NOTICE after all), but
> there
> > is a subtle difference between what has been fixed and what is broken
> now.
> > Passing NULLs to array_merge didn't lead to the borked arrays that have
> > been "fixed" by this patch.
> >
>
> How are the arrays borked? The patch doesn't touch, skip or otherwise do
> anything to any of the parameters, it just does a type check. Am I
> missing
> something here? (Which is quite possible...)
Ah, well, I misread the original bug report. With "borked" I meant that
array_merge(false, array("foo" => "bar")) resulted in array(0 => false,
"foo" => "bar"). I though this was changed by the patch.
Anyway, array_merge(array("foo" => "bar"), null) was never producing such an
array and should thus not result in an E_NOTICE.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>: > In my opinion the change is fine, given the current state of affairs a > transitional release between 4.3 & 5.0 does not seem likely. Therefor it > would only seem logical to give people a fair warning (E_NOTICE) that the > (wrong) behavior they are relying upon is not going work/last forever. > Otherwise, without a word of warning working code will suddenly become > broken > code once they upgrade. But they would expect their code to (potentially) break if they upgrade to PHP 5.0. And it actually will, despite the efforts to make 5.0 as BC as possible. > Most people have their error reporting set to E_ALL ^ E_NOTICE (do not > display > notices) so it won't affect them anyway. Even then, the behavior itself > implies a failure in some code, since an non-array value is passed to a > function expecting an array. I venture it would help a number of people > find > errors in their code that before were nigh impossible to find and/or > track > down. I generally agree (this is the purpose of E_NOTICE after all), but there is a subtle difference between what has been fixed and what is broken now. Passing NULLs to array_merge didn't lead to the borked arrays that have been "fixed" by this patch. > And yes PHP is typeless, but all of the code using new argument parsing > functions will most definitely reject strings passed to functions > expecting > arrays and vice versa. I see this situations as not being any different. Does this apply to NULL "values" too? Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
Hi, the recent change to array_merge that now checks for IS_ARRAY breaks BC IMO. At least I know get a lot of E_NOTICEs everywhere. On Tue, 23 Sep 2003, jan at horde dot org wrote: > ID: 25494 > Comment by: jan at horde dot org > Reported By: enygma at phpdeveloper dot org > Status: Bogus > Bug Type: Arrays related > Operating System: Any > PHP Version: 4.3.2 > New Comment: > >This fix also breaks BC in the way that previously allowed (and >working) NULLs being passed as arguments, now produce an unnecessary >E_NOTICE. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Incorrect locale support for decimal_point
Zitat von David Guerrero <[EMAIL PROTECTED]>: > Hi! > > I opened Bug #25246 some days ago. The bug was closed as "bogus" by > Sniper. > > I think that this issue (locale numeric settings) is not correctly > addressed in the php core. And i would like to open a discussion about > it, because i think is a very important one. > > As stated in the bug report, this breaks backward compatibility with 4.2 > and older releases. I think that an innapropiate patch broke this in the > end of 2002. > > The question is that databases returns float values with "," or "." > based in its own locale (good locale behavior). I can't understand why > php could not work with these settings as usual. Why the new "reset the > locale setting" is better? > > There is not a workaround solution for applications manipulating those > values (maybe an database function returning floats always with "."). > > Please, consider this as a genuine bug as this could make a lot of > people outside the US, to stick with older versions of PHP. 100% agreed, I already tried to put that on the agenda again, without luck: http://marc.theaimsgroup.com/?t=10499385931&r=1&w=2 Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php5 interfaces...
Zitat von Marcus BXrger <[EMAIL PROTECTED]>:
> Hello Tony,
>
> Friday, July 11, 2003, 9:39:55 PM, you wrote:
>
> TB> In PHP5 I noticed this behaviou with interfaces. If I have an
> interface
> TB> with a method that takes no paramaters, an implementing class for
> that
> TB> interfaces can have the same method take parameters...is that right?
> TB> For example:
>
> TB> interface foo {
> TB> public function myFunction();
> TB> }
>
> TB> class foobar implements foo {
> TB>public function myFunction($someText)
> TB> {
> TB> echo $someText;
> TB>}
> TB> }
>
> TB> $myObj = new foobar();
> $myObj->>myFunction('Testing, 1, 2, 3');
>
> TB> This code works. To me it should flag an error or, at least a
> warning,
> TB> no? I can see the flexibility of allowing this as it provides a
> kind-of
> TB> form of overloading but I want to make sure this behaves as intended
> TB> before I make use of this feature/bug.
>
> TB> --Tony
>
>
>
> PHP is a wek typed languagei see your point but we are not strict
> typed.
What does this have to do with typed languages? Interfaces are not types of
method implementations or some such.
There's also a warning if you call a function/method with too few or too
much arguments, that seems much more similar to this case for me.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs.php.net
Zitat von Robin Ericsson <[EMAIL PROTECTED]>: > On Wed, 2003-07-09 at 14:46, Jan Schneider wrote: > > Zitat von Stanislav Malyshev <[EMAIL PROTECTED]>: > > > > > JS>> Click on "View branches" ;-) > > > > > > I'm sorry I see no view branches on http://cvs.php.net/cvs.php/Zend. > > > Could > > > you please help me with URL? > > > > You can only see branches in the file view, not in the directory view, > > because directories can't be branched. > > > > How come viewcvs can do this but not Chora? Is this performance choice? Not sure if it was a performance choice at design time, but yes, it is a big perfomance hit because you had to look at each file's history to if it belongs to the specified branch. Beside that, patches are welcome at [EMAIL PROTECTED] ;-) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs.php.net
Zitat von Stanislav Malyshev <[EMAIL PROTECTED]>: > JS>> Click on "View branches" ;-) > > I'm sorry I see no view branches on http://cvs.php.net/cvs.php/Zend. > Could > you please help me with URL? You can only see branches in the file view, not in the directory view, because directories can't be branched. If you're just missing some files that still exist in one branch but were removed from HEAD, click on "Show deleted". Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cvs.php.net
Zitat von Edin Kadribasic <[EMAIL PROTECTED]>: > EK>> You need to check out -r PHP_4_3 as ze1 does not exist in head. > > >How do I "check out -r PHP_4_3" on cvs.php.net website? > > Sorry I didn't realise you were talking about web interface to the > cvs. > > I have no idea how to view branches in Chora. Click on "View branches" ;-) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] protected interface methods
Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (Marcus Börger) wrote: > > > Hello internals, > > > > It is of course correct that an interface method cannot be declared > private > > but i think it should be possible to declare it protected. > > I don't see the benefit to allow interfaces to have protected methods as > I > use abstracts for that purpose. What's your point? Agreed. As the name implies "interfaces" define interfaces to the outside not to extending classes. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] make test doesn't work on PHP_4_3
Zitat von Jani Taskinen <[EMAIL PROTECTED]>: > > Works fine here, get a fresh checkout. Doh! You shouldn't try to run the tester if you compiled --without-cli. ;-) > --Jani > > On Wed, 2 Jul 2003, Jan Schneider wrote: > > >/bin/sh: line 1: /home/jan/software/php43/: is a directory > >make: *** [test] Fehler 126 > > > >This is how the Makefile part looks like: > > > >test: $(SAPI_CLI_PATH) > >@TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \ > > TEST_PHP_SRCDIR=$(top_srcdir) \ > > CC="$(CC)" \ > >$(top_builddir)/$(SAPI_CLI_PATH) -d > 'open_basedir=' > >-d 'safe_mode=0' -d 'output_buffering=0' $(top_srcdir)/run-tests.php > >$(TESTS) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] make test doesn't work on PHP_4_3
/bin/sh: line 1: /home/jan/software/php43/: is a directory make: *** [test] Fehler 126 This is how the Makefile part looks like: test: $(SAPI_CLI_PATH) @TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \ TEST_PHP_SRCDIR=$(top_srcdir) \ CC="$(CC)" \ $(top_builddir)/$(SAPI_CLI_PATH) -d 'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' $(top_srcdir)/run-tests.php $(TESTS) Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] (ATTENTION) Pre-Beta
Zitat von Sterling Hughes <[EMAIL PROTECTED]>: > Source distro :: > > http://www.php.net/~sterling/php5/ > > Win32 binaries :: > > http://www.php.net/~edink/php-5.0.0b1-Win32.zip > > Download, compile, test. Just something that doesn't have something to do with the pre-beta, but this HEAD generally: I think the register globals warning can safely be removed from the configure script now. Btw, compiles and tests fine. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compile error with LDAP extension
Current HEAD: /home/jan/software/php5/ext/ldap/ldap.c: In function `_php_sasl_interact': /home/jan/software/php5/ext/ldap/ldap.c:474: error: `sasl_interact_t' undeclared (first use in this function) /home/jan/software/php5/ext/ldap/ldap.c:474: error: (Each undeclared identifier is reported only once /home/jan/software/php5/ext/ldap/ldap.c:474: error: for each function it appears in.) /home/jan/software/php5/ext/ldap/ldap.c:474: error: `interact' undeclared (first use in this function) /home/jan/software/php5/ext/ldap/ldap.c:476: error: `SASL_CB_LIST_END' undeclared (first use in this function) make: *** [ext/ldap/ldap.lo] Fehler 1 Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Module name change to mod_php5/libphp5
Hi, this is sort of a best-practices-question: I used to test our stuff with different PHP versions by having them in separate CVS checkouts and just calling "make install" in these directories and restarting Apache. This worked fine as long as all versions used the same names for their files, especially mod_php4.c and libphp4.so. This obviously doesn't work anymore now that these files have been renamed on HEAD. So I thought I'd take the good ol' --enable-versioning out of the box, but unfortunately PHP_4_3 and HEAD don't like each other very much. As soon as I access any PHP page I get a segfault. This backtrace is all information I can get: #0 0x in ?? () #1 0x4052bd74 in unique_id_module () from /usr/lib/apache/libphp4.so #2 0x4052ae7b in unique_id_module () from /usr/lib/apache/libphp4.so #3 0x405668ad in unique_id_module () from /usr/lib/apache/libphp4.so #4 0x405674ea in unique_id_module () from /usr/lib/apache/libphp4.so #5 0x405676a2 in unique_id_module () from /usr/lib/apache/libphp4.so #6 0x08054f7a in ap_invoke_handler () #7 0x080692f4 in process_request_internal () #8 0x0806957e in ap_process_request () #9 0x08061208 in child_main () #10 0x080614b5 in make_child () #11 0x0806154d in startup_children () #12 0x080620db in standalone_main () #13 0x0806246e in main () #14 0x401654a2 in __libc_start_main () from /lib/libc.so.6 Is there any other way to run both versions side by side or do I have to dis- and enable the modules in httpd.conf each time I want to try the other version? Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes_sybase and php_stripslashes
Quoting Jani Taskinen <[EMAIL PROTECTED]>: > Heh..so magic_quotes_sybase ini setting affects how stripslashes() > function works too? Pretty high WTF factor there. It should be > an additional option for php_stripslashes() that is passed where > appropriate. As long as it affects addslashes() it should also affect stripslashes(). The WTF factor would be even higher else. > On Mon, 31 Mar 2003, Sander Roobol wrote: > > >On Mon, Mar 31, 2003 at 03:45:13PM +0200, moshe doron wrote: > >> could some1 explain the first if here (php_stripslashes:cybase mode) > >> http://lxr.php.net/source/php4/ext/standard/string.c#2324 > >> that have nothing with slashes but with quotes? > > > >Sybase escapes ' with '' and NUL with \0 so we needed a special > >version of php_stripslashes(). > > > >Sander > > > >> > >> could this if be removed safely? Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZE2 race condition
Quoting Zeev Suraski <[EMAIL PROTECTED]>: > At 04:56 26/03/2003, Jan Schneider wrote: > >Quoting Zeev Suraski <[EMAIL PROTECTED]>: > > > > > That's quite intentional - assignments in ZE2 are handle based, > versus > > > the > > > value based in ZE1. That's more or less the biggest change in ZE2 :) > > > > > > If you want to create copies like in ZE1 you can use __clone(). > > > >That's true of course, but serialize() still shouldn't segfault, no? > > Of course it's a bad idea for anything to segfault :) It's not ZE2's > fault, though... No, but we know that ZE2 can do it better. Looking at the output of var_dump() it seems that it is able to detect infinite recursion, is there a (technical) reason that the same detection isn't applied to serialize()? Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZE2 race condition
Quoting Zeev Suraski <[EMAIL PROTECTED]>:
> That's quite intentional - assignments in ZE2 are handle based, versus
> the
> value based in ZE1. That's more or less the biggest change in ZE2 :)
>
> If you want to create copies like in ZE1 you can use __clone().
That's true of course, but serialize() still shouldn't segfault, no?
> At 06:13 25/03/2003, Jan Schneider wrote:
> >Running the following code:
> >
> >class Foo {
> > var $bar_ref;
> >}
> >
> >class Bar {
> > var $foo_ref;
> >}
> >
> >$foo = new Foo();
> >$bar = new Bar();
> >$foo->bar_ref = $bar;
> >$bar->foo_ref = $foo;
> >
> >var_dump($foo);
> >var_dump($bar);
> >
> >$s = serialize($foo);
> >var_dump($s);
> >$s = serialize($bar);
> >var_dump($s);
> >
> >
> >in PHP_4_3 results to:
> >
> >object(foo)(1) {
> > ["bar_ref"]=>
> > object(bar)(1) {
> > ["foo_ref"]=>
> > NULL
> > }
> >}
> >object(bar)(1) {
> > ["foo_ref"]=>
> > object(foo)(1) {
> > ["bar_ref"]=>
> > object(bar)(1) {
> > ["foo_ref"]=>
> > NULL
> > }
> > }
> >}
> >string(58) "O:3:"foo":1:{s:7:"bar_ref";O:3:"bar":1:{s:7:"foo_ref";N;}}"
> >string(86)
>
>"O:3:"bar":1:{s:7:"foo_ref";O:3:"foo":1:{s:7:"bar_ref";O:3:"bar":1:{s:7:"foo_ref";N;}}}"
> >
> >
> >in HEAD:
> >
> >object(foo)#1 (1) {
> > ["bar_ref"]=>
> > object(bar)#2 (1) {
> > ["foo_ref"]=>
> > object(foo)#1 (1) {
> > ["bar_ref"]=>
> > object(bar)#2 (1) {
> > ["foo_ref"]=>
> > *RECURSION*
> > }
> > }
> > }
> >}
> >object(bar)#2 (1) {
> > ["foo_ref"]=>
> > object(foo)#1 (1) {
> > ["bar_ref"]=>
> > object(bar)#2 (1) {
> > ["foo_ref"]=>
> > object(foo)#1 (1) {
> > ["bar_ref"]=>
> > *RECURSION*
> > }
> > }
> > }
> >}
> >
> >and a segfault (apache 1 sapi) or a runaway process (cli sapi).
> >
> >Jan.
> >
> >--
> >http://www.horde.org - The Horde Project
> >http://www.ammma.de - discover your knowledge
> >http://www.tip4all.de - Deine private Tippgemeinschaft
> >
> >--
> >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
>
>
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZE2 race condition
Running the following code:
class Foo {
var $bar_ref;
}
class Bar {
var $foo_ref;
}
$foo = new Foo();
$bar = new Bar();
$foo->bar_ref = $bar;
$bar->foo_ref = $foo;
var_dump($foo);
var_dump($bar);
$s = serialize($foo);
var_dump($s);
$s = serialize($bar);
var_dump($s);
in PHP_4_3 results to:
object(foo)(1) {
["bar_ref"]=>
object(bar)(1) {
["foo_ref"]=>
NULL
}
}
object(bar)(1) {
["foo_ref"]=>
object(foo)(1) {
["bar_ref"]=>
object(bar)(1) {
["foo_ref"]=>
NULL
}
}
}
string(58) "O:3:"foo":1:{s:7:"bar_ref";O:3:"bar":1:{s:7:"foo_ref";N;}}"
string(86)
"O:3:"bar":1:{s:7:"foo_ref";O:3:"foo":1:{s:7:"bar_ref";O:3:"bar":1:{s:7:"foo_ref";N;}}}"
in HEAD:
object(foo)#1 (1) {
["bar_ref"]=>
object(bar)#2 (1) {
["foo_ref"]=>
object(foo)#1 (1) {
["bar_ref"]=>
object(bar)#2 (1) {
["foo_ref"]=>
*RECURSION*
}
}
}
}
object(bar)#2 (1) {
["foo_ref"]=>
object(foo)#1 (1) {
["bar_ref"]=>
object(bar)#2 (1) {
["foo_ref"]=>
object(foo)#1 (1) {
["bar_ref"]=>
*RECURSION*
}
}
}
}
and a segfault (apache 1 sapi) or a runaway process (cli sapi).
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __LINE__ != __LINE__?
Quoting Edin Kadribasic <[EMAIL PROTECTED]>:
> > Current HEAD:
> >
> > die("line: " . __LINE__) works as expected, but die(__LINE__)
> doesn't output
> > anything.
>
> That's because die(int) will set exit status and not print anything.
> die(string) prints string and exits.
Hm, that should perhaps be added to the manual. According to the user notes
the same applies to exit.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] __LINE__ != __LINE__?
Current HEAD:
die("line: " . __LINE__) works as expected, but die(__LINE__) doesn't output
anything.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Variable method names
Is there a reason or is it a bug that the following code doesn't work anymore?
class Foo {
function bar()
{
echo "bar";
}
}
$method = "bar";
Foo::$method();
parse error, unexpected '('
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fields of extended class not instatiated
Quoting Zeev Suraski <[EMAIL PROTECTED]>:
> Should be fixed now. Thanks for the test case!
>
> Zeev
>
> At 17:43 22/03/2003, Jan Schneider wrote:
> >This code run in current code (HEAD):
> >
> >class Foo {
> > var $arr = array();
> >}
> >
> >class FooX extends Foo {
> > function bar()
> > {
> > var_dump($this->arr);
> >
> > }
> >}
> >
> >$foo = new FooX();
> >$foo->bar();
> >
> >produces "NULL" as the output. I guess this is not the intended
> behaviour?
Yes, works great now.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fields of extended class not instatiated
This code run in current code (HEAD):
class Foo {
var $arr = array();
}
class FooX extends Foo {
function bar()
{
var_dump($this->arr);
}
}
$foo = new FooX();
$foo->bar();
produces "NULL" as the output. I guess this is not the intended behaviour?
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
