[PHP-DEV] advice request on new php extension : phprep
Hi, internals.
[Introduction]
I'm working on new php extension.
It's called "phprep". It's a glue between php and librep.
Why? PHP have a lot of good libs, lisp have the power and
this is my attempt to combine.
(Please no flames about power of langs.)
I want the extension to be open-source.
I want to start using this extension (as soon as it becomes
pretty stable e.t.c) at my work.
The extension was (already half of it or more i guess) written
in my spare time.
[How]
Two functions implemented
In php:
rep_eval($str) : evaluates $str lisp code and converts any returned
data structure into php data structure.
In librep:
(eval-php str) : the exact opposite
Thise two should be enough.
[Simple example]
---
$in=array(1,2,3,4,5);
$out=rep_eval('(filter oddp (eval-php "$in"))');
print_r($out);
---
Array
(
[0] => 1
[1] => 3
[2] => 5
)
---
[TODO]
Stabilize the code.
Finish data converters.
They already handle most primitives and arrays(hashes) but that might be
not the best
implementation alternative (talking about arrays).
[Questions]
Is sf.net the right place to publish?
Do I have restrictions (because it's a php extension)
on picking up a license for the soft?
(I mean except ones on sf.net)
I want to publish first and than introduce that to my boss.
Seems to be the correct order?
What are my chances the people will join the project after
i will publish it ?
Any other ideas ?
P.S.
RTFM pointers are perfectly fine. They should contain urls tough :)
--
NetCat
--
SPAM-Free 10mb Free email + Antivirus + POP3 + more...
Get it at http://www.doal.co.il:81/free/?c=all-spam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] advice request on new php extension : phprep
> From: netcat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 08, 2003 9:30 AM > Is sf.net the right place to publish? > Do I have restrictions (because it's a php extension) > on picking up a license for the soft? > (I mean except ones on sf.net) you may want to look here: http://pecl.php.net/account-request.php regards, Lukas -- 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)
On Tue, 7 Oct 2003, Jon Parise wrote: > On Mon, Oct 06, 2003 at 07:10:20PM -0400, Ilia Alshanetsky wrote: > > > 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. > > That's an elitist and unprofessional stance. It's not. If you misuse a language, then you pay for it. Derick -- - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- 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)
On Tue, 7 Oct 2003, Jon Parise wrote: > On Tue, Oct 07, 2003 at 08:36:11PM -0400, Ilia Alshanetsky wrote: > > > On October 7, 2003 08:19 pm, Jon Parise wrote: > > > By your definition, the code was "proper" (i.e. did not generate > > > warnings) until the underlying rules were changed, and I'm sure we all > > > agree that that's a silly definition of "proper code". > > > > Well, you are claiming that a code that relies on an illogical and > > undocumented 'feature' is proper? > > No, I'm not. I'm saying it used to run without producing any errors, You mean just like our bison parser? > Which just goes to show that the authors of the PEAR library (who are > not ignorant of the PHP language and its constraints) were under the > assumption that the code was correct at the time that is was written. Then they were wrong... Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch providing new function apache_get_scoreboard()
Hello,
Here's a patch against PHP_4 that provides a new function called
apache_get_scoreboard(). The function returns an array containing
current scoreboard.
The idea behind this is to provide a flexible way to dump Apache
scoreboard. There are several applications that I can think of : a tool
such as Apache::VMonitor (ie mod_status page on steroïds), dumping the
scoreboard in XML format for a monitoring application (that would also
generate graphs representing Apache activity), or text format for a
command-line tool, etc.
There's a drawback though, which somewhat breaks the "rule" (if any)
"write once run everywhere" because Apache scoreboard structure depends
on the platform and on the version of Apache. I chose however for
simplicity to do a strict mapping of the structure.
I've attached a supersimple test script.
This is my first PHP hack so comments are welcome,
Thank you,
Olivier
Index: sapi/apache/php_apache.c
===
RCS file: /repository/php-src/sapi/apache/php_apache.c,v
retrieving revision 1.69.2.3
diff -u -r1.69.2.3 php_apache.c
--- sapi/apache/php_apache.c3 Jan 2003 21:32:24 - 1.69.2.3
+++ sapi/apache/php_apache.c8 Oct 2003 08:23:09 -
@@ -44,6 +44,7 @@
PHP_FUNCTION(apache_lookup_uri);
PHP_FUNCTION(apache_child_terminate);
PHP_FUNCTION(apache_setenv);
+PHP_FUNCTION(apache_get_scoreboard);
PHP_MINFO_FUNCTION(apache);
@@ -55,6 +56,7 @@
PHP_FE(apache_child_terminate, NULL)
PHP_FE(apache_setenv, NULL)
PHP_FE(apache_response_headers, NULL)
+ PHP_FE(apache_get_scoreboard, NULL)
PHP_FALIAS(getallheaders, apache_request_headers, NULL)
{NULL, NULL, NULL}
};
@@ -82,6 +84,17 @@
#else
php_apache_globals_ctor(&php_apache_info TSRMLS_CC);
#endif
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_DEAD", SERVER_DEAD, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_STARTING", SERVER_STARTING, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_READY", SERVER_READY, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_BUSY_READ", SERVER_BUSY_READ, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_BUSY_WRITE", SERVER_BUSY_WRITE, CONST_CS
| CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_BUSY_KEEPALIVE", SERVER_BUSY_KEEPALIVE,
CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_BUSY_LOG", SERVER_BUSY_LOG, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_BUSY_DNS", SERVER_BUSY_DNS, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_SERVER_GRACEFUL", SERVER_GRACEFUL, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_HARD_SERVER_LIMIT", HARD_SERVER_LIMIT, CONST_CS
| CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("APACHE_EXTENDED_STATUS", ap_extended_status, CONST_CS
| CONST_PERSISTENT);
REGISTER_INI_ENTRIES();
return SUCCESS;
}
@@ -474,6 +487,142 @@
}
/* }}} */
+/* {{{ proto array apache_get_scoreboard(void)
+ Fetch Apache scoreboard */
+PHP_FUNCTION(apache_get_scoreboard)
+{
+zval *rv_global, *rv_parent, *parent_z, *rv_servers, *servers_z;
+parent_score scoreboard_parent_rec;
+short_score scoreboard_servers_rec;
+ int i;
+#if MODULE_MAGIC_NUMBER >= 19981204
+server_rec *vhost;
+#endif
+#ifndef NO_TIMES
+zval *times_z;
+#endif
+#if !defined(NO_GETTIMEOFDAY)
+zval *start_time_z, *stop_time_z;
+#endif
+
+if (array_init(return_value) == FAILURE) {
+RETURN_FALSE;
+}
+
+if (!ap_exists_scoreboard_image()) {
+php_error_docref(NULL TSRMLS_CC, E_WARNING, "scoreboard is not available");
+RETURN_FALSE;
+}
+
+ap_sync_scoreboard_image();
+
+MAKE_STD_ZVAL(rv_global);
+if (array_init(rv_global) == FAILURE) {
+RETURN_FALSE;
+}
+#if MODULE_MAGIC_NUMBER >= 19981204
+add_assoc_long(rv_global, "running_generation",
(long)ap_scoreboard_image->global.running_generation);
+#else
+ add_assoc_long(rv_global, "exit_generation",
(long)ap_scoreboard_image->global.exit_generation);
+#endif
+MAKE_STD_ZVAL(rv_parent);
+if (array_init(rv_parent) == FAILURE) {
+RETURN_FALSE;
+}
+MAKE_STD_ZVAL(rv_servers);
+if (array_init(rv_servers) == FAILURE) {
+RETURN_FALSE;
+}
+
+for (i = 0; i < HARD_SERVER_LIMIT; ++i) {
+
+MAKE_STD_ZVAL(parent_z);
+if (array_init(parent_z) == FAILURE) {
+RETURN_FALSE;
+}
+scoreboard_parent_rec = ap_scoreboard_image->parent[i];
+add_assoc_long(parent_z, "pid", (long)scoreboard_parent_rec.pid);
+#ifdef OPTIMIZE_TIMEOUTS
+add_assoc_long(parent_z, "last_rtime", scoreboard_parent_rec.l
Re: [PHP-DEV] advice request on new php extension : phprep
> [Questions] > > Is sf.net the right place to publish? As Lukas pointed out, why use sf.net to host your PHP extension when you can use the PHP facilities? :-) Please read this link for more information about PECL: http://news.php.net/article.php?group=php.pecl.dev&article=5 > Do I have restrictions (because it's a php extension) > on picking up a license for the soft? > (I mean except ones on sf.net) In terms of licensing, BSD and non-viral Open Source licenses are suitable for use with a PECL-hosted extension. We strongly recommend that all PECL extensions are licensed using our own PHP License. If you are wrapping a library (which you are), the library itself can be LGPL provided that you don't bundle a modified version of it with the extension. However, if the library is GPL, that would cause your extension to become a GPL extension, and we can't have GPL code in PECL. Unfortunately, librep itself falls under the GPL, which means that we can't host your extension in PECL (please check the archives for pecl-dev list for more information). If you can find a BSD licensed alternative for librep, then it would be welcome. You are also welcome to propose other extensions for PECL. So, it looks like sf.net is your best option right now. > I want to publish first and than introduce that to my boss. > Seems to be the correct order? Depends on your boss ;-) > What are my chances the people will join the project after > i will publish it ? If the extension seems to be quite useful to a number of people, then the chances are quite good. --Wez. -- 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)
At 03:00 08/10/2003, Ilia Alshanetsky wrote: 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 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. Ilia, The fact of the matter is that other than your opinion (which several people may support), there was and still isn't nothing problematic with silently ignoring NULL arrays. A thing that's known to break pieces of code, must not be 'fixed' in a bug fix release - this is completely and entirely obvious IMHO, and was a rule we always tried to go by in the past. I agree with others here that whether it should be changed altogether is debatable, considering the nature of PHP, and the fact that it has no problems whatsoever to treat NULL values as empty arrays, by design. It should be debated in the context of a feature-release though, not a bug-fix release. As a rule of the thumb - if you bump into something that broke compatibility and you found it even before releasing, it means it affects TONS of users. If it was an important security issue, then it might have been worth it. If it's a small nuance about code purity, it isn't worth it... Zeev -- 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)
At 10:06 08/10/2003, Derick Rethans wrote: On Tue, 7 Oct 2003, Jon Parise wrote: > On Mon, Oct 06, 2003 at 07:10:20PM -0400, Ilia Alshanetsky wrote: > > > 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. > > That's an elitist and unprofessional stance. It's not. If you misuse a language, then you pay for it. That's also an elitist statement IMHO. Are you gaining anything form making these people 'pay'? Who is to define what constitutes use and what constitutes misuse? Generally, if it works, and it's not horribly illogical, then it's a valid use. Zeev -- 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)
At 10:10 08/10/2003, Derick Rethans wrote: On Tue, 7 Oct 2003, Jon Parise wrote: > On Tue, Oct 07, 2003 at 08:36:11PM -0400, Ilia Alshanetsky wrote: > > > On October 7, 2003 08:19 pm, Jon Parise wrote: > > > By your definition, the code was "proper" (i.e. did not generate > > > warnings) until the underlying rules were changed, and I'm sure we all > > > agree that that's a silly definition of "proper code". > > > > Well, you are claiming that a code that relies on an illogical and > > undocumented 'feature' is proper? > > No, I'm not. I'm saying it used to run without producing any errors, You mean just like our bison parser? If you refer to the INI parser, then it's actually an example of a change that broke compatibility, probably made after the bison people thought that nobody uses this feature. > Which just goes to show that the authors of the PEAR library (who are > not ignorant of the PHP language and its constraints) were under the > assumption that the code was correct at the time that is was written. Then they were wrong... Says who? With PHP, the number 1 source to describe the functionality is the functionality itself. Even if it was documented to the contrary, at this point I would have to say that it was the documentors (which are, like the rest of us, mere mortals that make mistakes) who were wrong. And in this case, even if the PEAR authors were wrong, why on earth force them as well as lots of others pay when you can let go on working without any drawbacks whatsoever? This unexplained will to break compatibility is something that's very difficult to understand. Zeev -- 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)
On Wednesday, Oct 8, 2003, at 11:12 Europe/Copenhagen, Zeev Suraski wrote: The fact of the matter is that other than your opinion (which several people may support), there was and still isn't nothing problematic with silently ignoring NULL arrays. I hope the same reasoning, which I completely agree with, can be applied to foreach which now spits out a warning for non-arrays. At least reduce the warning to notice. Can you see any harm if foreach silently ignored non-array arguments (as opposed to loudly ignoring them now)? Edin -- 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)
At 11:49 08/10/2003, Edin Kadribasic wrote: On Wednesday, Oct 8, 2003, at 11:12 Europe/Copenhagen, Zeev Suraski wrote: The fact of the matter is that other than your opinion (which several people may support), there was and still isn't nothing problematic with silently ignoring NULL arrays. I hope the same reasoning, which I completely agree with, can be applied to foreach which now spits out a warning for non-arrays. At least reduce the warning to notice. Can you see any harm if foreach silently ignored non-array arguments (as opposed to loudly ignoring them now)? I think it should ignore NULL values, but non other scalar non array values can be more problematic and probably implies an error. Was this behavior changed in any way in 4.3.x? Zeev -- 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)
On Wednesday, Oct 8, 2003, at 12:49 Europe/Copenhagen, Zeev Suraski wrote: At 11:49 08/10/2003, Edin Kadribasic wrote: On Wednesday, Oct 8, 2003, at 11:12 Europe/Copenhagen, Zeev Suraski wrote: The fact of the matter is that other than your opinion (which several people may support), there was and still isn't nothing problematic with silently ignoring NULL arrays. I hope the same reasoning, which I completely agree with, can be applied to foreach which now spits out a warning for non-arrays. At least reduce the warning to notice. Can you see any harm if foreach silently ignored non-array arguments (as opposed to loudly ignoring them now)? I think it should ignore NULL values, but non other scalar non array values can be more problematic and probably implies an error. Was this behavior changed in any way in 4.3.x? No this behavior hasn't been changed. I just thought that no harm would be done if it was changed and no warning was issued. Edin -- 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)
On Wed, Oct 08, 2003 at 01:23:42PM +0200, Edin Kadribasic wrote: > > No this behavior hasn't been changed. I just thought that no harm would > be done if it was changed and no warning was issued. I think the point is to minimise the number of changes in this ``bug-fix release'', and that applies to adding _and_ removing warnings if they aren't critical to fixing a real bug. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridgehttp://www.cl.cam.ac.uk -- 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)
On Wednesday, Oct 8, 2003, at 13:48 Europe/Copenhagen, Anil Madhavapeddy wrote: On Wed, Oct 08, 2003 at 01:23:42PM +0200, Edin Kadribasic wrote: No this behavior hasn't been changed. I just thought that no harm would be done if it was changed and no warning was issued. I think the point is to minimise the number of changes in this ``bug-fix release'', and that applies to adding _and_ removing warnings if they aren't critical to fixing a real bug. I'm not advocating that foreach behavior should be changed in 4.3.4. I'm just saying that it would be convenient if it ignored NULL/unitialized/false value. Edin -- 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)
On October 8, 2003 05:12 am, Zeev Suraski wrote: > The fact of the matter is that other than your opinion (which several > people may support), there was and still isn't nothing problematic with > silently ignoring NULL arrays. Jay's patch was already reverted by Jani so arguing this point is mostly moot. However, please note the following: 1) Functionality was NOT changed in 4.3.4 a mere advisory was added indicated a behavior change in PHP5. 2) Nearly every single array function will return E_WARNING when it encounters and argument that is not an array or an object. 3) New argument parsing API when told to expect an array "a" will return an error when a non-array value is provided. Ilia -- 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)
At 14:34 08/10/2003, Ilia Alshanetsky wrote: On October 8, 2003 05:12 am, Zeev Suraski wrote: > The fact of the matter is that other than your opinion (which several > people may support), there was and still isn't nothing problematic with > silently ignoring NULL arrays. Jay's patch was already reverted by Jani so arguing this point is mostly moot. Cool, I missed that, but I think it's important to have a general guideline for future cases either way. However, please note the following: 1) Functionality was NOT changed in 4.3.4 a mere advisory was added indicated a behavior change in PHP5. What do you mean by a mere advisory? 2) Nearly every single array function will return E_WARNING when it encounters and argument that is not an array or an object. 3) New argument parsing API when told to expect an array "a" will return an error when a non-array value is provided. Quite possible, but it's still debatable whether it should be that way or not. Speaking of consistency, the class type hints in ZE2 don't prevent you (at least by default) the ability to pass in NULL values. Extending this to the way arrays are handled in builtin functions makes sense to me. Zeev -- 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)
On October 8, 2003 08:53 am, Zeev Suraski wrote: > >However, please note the following: > >1) Functionality was NOT changed in 4.3.4 a mere advisory was added > > indicated a behavior change in PHP5. > > What do you mean by a mere advisory? In 4.3.X the patch only added E_NOTICE that majority of users block anyway and it was added to indicate a behavior change in 5.0. I felt that was a good idea since it is unlikely we'd have an in between 4.3.X - 5.0 release. This way people are made aware of the pending change. My main reason for wanting an E_NOTICE in 4.3.X was to warn people of the change (since we have an opportunity to do so) rather then have their code suddenly break when upgrading to 5.0. > Quite possible, but it's still debatable whether it should be that way or > not. Speaking of consistency, the class type hints in ZE2 don't prevent you > (at least by default) the ability to pass in NULL values. Extending this > to the way arrays are handled in builtin functions makes sense to me. Good point. What about other values such as bool, int, etc... We could convert them to array(bool|int|etc...) and thus allow complete non-array argument support for array functions. Ilia -- 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)
At 15:07 08/10/2003, Ilia Alshanetsky wrote: On October 8, 2003 08:53 am, Zeev Suraski wrote: > >However, please note the following: > >1) Functionality was NOT changed in 4.3.4 a mere advisory was added > > indicated a behavior change in PHP5. > > What do you mean by a mere advisory? In 4.3.X the patch only added E_NOTICE that majority of users block anyway and it was added to indicate a behavior change in 5.0. I felt that was a good idea since it is unlikely we'd have an in between 4.3.X - 5.0 release. This way people are made aware of the pending change. My main reason for wanting an E_NOTICE in 4.3.X was to warn people of the change (since we have an opportunity to do so) rather then have their code suddenly break when upgrading to 5.0. Well, E_NOTICE is a bit more aggressive than a mere advisory, since it plugs into your application and may effect the way it behaves... > Quite possible, but it's still debatable whether it should be that way or > not. Speaking of consistency, the class type hints in ZE2 don't prevent you > (at least by default) the ability to pass in NULL values. Extending this > to the way arrays are handled in builtin functions makes sense to me. Good point. What about other values such as bool, int, etc... We could convert them to array(bool|int|etc...) and thus allow complete non-array argument support for array functions. I don't think it extends there very naturally, or at all for that matter. NULL is special because it's what empty variables evaluate to, and makes for a very typical initial value of an array. Zeev -- 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)
On Wed, 8 Oct 2003, Zeev Suraski wrote: > I don't think it extends there very naturally, or at all for that > matter. NULL is special because it's what empty variables evaluate to, and > makes for a very typical initial value of an array. I agree with that, allowing NULL instead of an array is fine... autoconverting scalars to an array sounds too magical to me. Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] version_compare(): 1 != 1.0 != 1.0.0
What's the logic behind version_compare() thinking that 1 < 1.0 < 1.0.0?
Talking about the versionning world, to me look quiet obvious that all
these should be equivalent. If PHP 5.0 is released the next release
won't be 5.0.0, will be 5.0.1 intead.
That could lead in problems with software dependecies, because I'd need
to know the amount of "digits" the next version will have for setting
the exact dependency on it. This is, I can't set a dep in PHP6 to
greater or equal than 6.0.0 because probably it would be 6.0 or even
just 6. I'd need to set the dep to "6" if want to cover all the cases
and doesn't look very clear for a normal user.
Test cases:
$ php -r "var_dump(version_compare('1', '1.0'));"
int(-1)
$ php -r "var_dump(version_compare('1.0', '1.0.0'));"
int(-1)
Tomas V.V.Cox
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP] Re: [PHP-DEV] File upload meter
* Thus wrote Curt Zirzow ([EMAIL PROTECTED]): > > You might get better and more authorative feedback if you post this > question to the php-dev list. Oops, I didn't realize this was crossposted.. sorry. Curt -- "My PHP key is worn out" PHP List stats since 1997: http://zirzow.dyndns.org/html/mlists/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] File upload meter
Hi Group, It's really nice to see the file upload meter developed by Doru Theodor Petrescu (http://pdoru.from.ro/). He did a nice job. He created serveral patches for the php 4 to enable the file upload meter. I was just wondering what will happen to the file upload meter once the php 5.0 will release? Is PHP community planning to put file upload meter code permanently in every distributions of the php? Please let me know about my queries. I really want to use this feature but worrying for the future php releases. Thanks Regards, Hardik Doshi __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File upload meter
* Thus wrote Hardik Doshi ([EMAIL PROTECTED]): > Hi Group, > > It's really nice to see the file upload meter > developed by Doru Theodor Petrescu > (http://pdoru.from.ro/). He did a nice job. He created > serveral patches for the php 4 to enable the file > upload meter. > > I was just wondering what will happen to the file > upload meter once the php 5.0 will release? Is PHP > community planning to put file upload meter code > permanently in every distributions of the php? > > Please let me know about my queries. I really want to > use this feature but worrying for the future php > releases. You might get better and more authorative feedback if you post this question to the php-dev list. Curt -- "My PHP key is worn out" PHP List stats since 1997: http://zirzow.dyndns.org/html/mlists/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Object Equality
(Note: this email seems to relate to this list in my opinion, but I have been chewed out before when posting such emails) I am using PHP 4.3.2, and it seems that testing objects for equality (with == or ===) causes an internal bug when the objects have recursive instance variables. That is, if the objects being tested have a variable that is a reference to an object that has a variable that is a reference to the first object, then the PHP processor dies. What can be done about this? If this needs to be sent to another mailing list, please let me know. Thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Equality
On Wed, 2003-10-08 at 10:21, [EMAIL PROTECTED] wrote:
> (Note: this email seems to relate to this list in my opinion, but I
> have been chewed out before when posting such emails)
>
> I am using PHP 4.3.2, and it seems that testing objects for equality
> (with == or ===) causes an internal bug when the objects have recursive
> instance variables. That is, if the objects being tested have a
> variable that is a reference to an object that has a variable that is a
> reference to the first object, then the PHP processor dies. What can be
> done about this? If this needs to be sent to another mailing list,
> please let me know.
Dirty hack -- create a unique ID instance variable for objects via their
constructor. Implement equality check with:
if( $obj1->uid == $obj2->uid )
{
// Same object, yaaay!
}
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
