Re: [PHP-DEV] RFC: Comparable interface
On Tue, October 5, 2010 5:44 am, Gustavo Lopes wrote:
On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch c...@l-i-e.com
wrote:
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote:
* The current behavior for , , etc. is completely useless. It's
unpredictable and it doesn't even establish a total order:
$a = new stdclass;
$a-prop = null;
$b = new stdclass;
$b-prop2 = null;
var_dump($a $b); //false
var_dump($a == $b); //false
var_dump($b $a); //false
E.
Which one of these would you expect to be true?...
They're sure not equal, right?
And what would make $a or $b greater than the other? I mean, *WHY*
would you expect one of those to be true, if you do expect one of
them to be true?
I sure can't find any logical a priori ordering, total, partial, or
otherwise.
Last time I checked, there was no rule that any set/graph or other
mathematical collection had to have a defined ordering, even
partial.
But it's been ages since I got my Honors Math degree, so maybe they
changed the rule while I wasn't looking... :-)
Without addressing the appeal to authority argument, the problem is
not
that there must be an ordering, partial or total.
The problem is that several algorithms expect a total order criterion
to
exist; a notable example are sorting functions. While many will still
terminate when given a partial order, the results will be
unpredictable.
So basically you have comparison function for objects, but you cannot,
in
general, use it to sort even objects of the same class (seem my
example).
But surely the generic case of an Object simply doesn't HAVE a
partial much less total ordering.
Forcing one to exist because a function exists that requires a stable
full ordering in order to call that function...
That's like forcing any string to be a valid JPEG because you might
feed it to imagecreatefromstring(), in my eyes.
Note that e.g. Java and .NET require a total order, see:
PHP is not Java.
PHP is not .Net
I really don't see a valid reason why any given random collection of
OOP instances would a priori have to have a total ordering available
to them.
Certainly, I can see a zillion cases where domain-specific knowledge
of the objects and a comparison function/operator should be definable.
But I strongly object to forcing EVERY random collection of objects to
have a total ordering. It's creating order where order does not
exist.
It would be somewhat useful to be able to sort objects by some
(arbitrary)
total ordering criterion, e.g. to do a binary search afterwards, but
that's marginal to my argument, which is that the current object
comparison behavior ranges from limited to useless. Therefore, some
addition that would allow the user to give meaningful behavior to the
operators in some limited circumstances (e.g. comparisons inside
classes
with inheritance relationships only) would be a good idea.
I can certainly see why it would be useful to allow it in some cases.
But how tricky is it to write:
function foo_cmp($foo1, $foo2){ ... }
and hand that to usort?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Comparable interface
On Wed, 06 Oct 2010 16:32:40 +0100, Richard Lynch c...@l-i-e.com wrote:
On Tue, October 5, 2010 5:44 am, Gustavo Lopes wrote:
On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch c...@l-i-e.com wrote:
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote:
* The current behavior for , , etc. is completely useless. It's
unpredictable and it doesn't even establish a total order:
$a = new stdclass;
$a-prop = null;
$b = new stdclass;
$b-prop2 = null;
var_dump($a $b); //false
var_dump($a == $b); //false
var_dump($b $a); //false
[...]
Last time I checked, there was no rule that any set/graph or other
mathematical collection had to have a defined ordering, even
partial.
[...]
[...] the problem is not that there must be an ordering, partial or
total.
[...] You have comparison function for objects, but you cannot,
in general, use it to sort even objects of the same class (seem my
example).
But surely the generic case of an Object simply doesn't HAVE a
partial much less total ordering.
[...]
Note that e.g. Java and .NET require a total order, see:
PHP is not Java.
PHP is not .Net
I'm sorry, is this an argument?
You obviously don't know and didn't bother to check the details of the
Comparable interfaces in those languages and therefore did not understand
my point. They require a total ordering because that's precisely the only
way the comparison function can be useful for most applications. But
precisely because it doesn't make sense, as you say, to have total
ordering for the full set of objects, not all objects implement such
interface.
This contrasts with PHP, which allows without error comparison of all
objects, but you can't do anything useful with it.
Certainly, I can see a zillion cases where domain-specific knowledge
of the objects and a comparison function/operator should be definable.
But I strongly object to forcing EVERY random collection of objects to
have a total ordering. It's creating order where order does not
exist.
I don't care either way, but, if implemented an arbitrary total order
(e.g. using the object id), it wouldn't be worse than the status quo.
It would be somewhat useful to be able to sort objects by some
(arbitrary)
total ordering criterion, e.g. to do a binary search afterwards, but
that's marginal to my argument, which is that the current object
comparison behavior ranges from limited to useless. Therefore, some
addition that would allow the user to give meaningful behavior to the
operators in some limited circumstances (e.g. comparisons inside
classes with inheritance relationships only) would be a good idea.
I can certainly see why it would be useful to allow it in some cases.
But how tricky is it to write:
function foo_cmp($foo1, $foo2){ ... }
and hand that to usort?
It's not tricky, but it's besides the point. We don't need many other
operators either, we could just write a custom function and use it instead.
The point is -- I'm going to reiterate this one last time -- for objects,
you can't do anything useful with the current zend_compare_function,
therefore a limited mechanism for overloading it would be useful.
Notice you didn't provide any argument otherwise and instead admitted (for
whatever reason) I was defending a total order should be established for
all the objects.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH]call exit in user error handler cause PHP stream core dump
Hi:
because in PHP exit is implements by set/longjmp
when use set_error_handler, and call exit in use_handler,
according to the normal sequence
1. php_stream_wrapper_log_error
2. php_stream_display_wrapper_errors
- php_error_docref1
3. php_stream_tidy_wrapper_error_log
the actual execution sequence will be:
1. php_stream_wrapper_log_error
2. php_stream_display_wrapper_errors
- php_error_docref1
3. use error handler
4. zend_bailout the php_stream_tidy_wrapper_error_log to be miss called.
then cause wrap-err_count doesn't reset to zero after request shutdown.
considering the PHP stream wrapper is a persistent struct,
when a new request coming the following code will code coredump in php_stream_display_wrapper_errors
for (i = 0, l = 0; i wrapper-err_count; i++) {
l += strlen(wrapper-err_stack[i]); //core
if (i wrapper-err_count - 1) {
l += brlen;
}
}
bug : http://bugs.php.net/bug.php?id=52935
thanks
--
惠新宸 Xinchen.Hui
| Engineer @ ECOM | (+8610)59926238
| laruence
diff -Naur php-5.2.14/main/streams/streams.c
php-5.2.14-new/main/streams/streams.c
--- php-5.2.14/main/streams/streams.c 2010-09-27 23:29:13.0 +0800
+++ php-5.2.14-new/main/streams/streams.c 2010-09-28 10:38:22.0
+0800
@@ -175,6 +175,7 @@
}
php_strip_url_passwd(tmp);
+ php_stream_tidy_wrapper_error_log(wrapper TSRMLS_CC);
php_error_docref1(NULL TSRMLS_CC, tmp, E_WARNING, %s: %s, caption,
msg);
efree(tmp);
if (free_msg) {
@@ -1773,7 +1774,6 @@
if (stream == NULL (options REPORT_ERRORS)) {
php_stream_display_wrapper_errors(wrapper, path, failed to
open dir TSRMLS_CC);
}
- php_stream_tidy_wrapper_error_log(wrapper TSRMLS_CC);
return stream;
}
@@ -1896,7 +1896,6 @@
*opened_path = NULL;
}
}
- php_stream_tidy_wrapper_error_log(wrapper TSRMLS_CC);
#if ZEND_DEBUG
if (stream == NULL copy_of_path != NULL) {
pefree(copy_of_path, persistent);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using child classes/interfaces as desired type hints
Hi,
Probly rehashing an old conversation here, but I'm wondering why the
following isn't supported
?php
abstract class AbstractServer {}
class ConcreteServer extends AbstractServer {}
abstract class AbstractClient {
abstract function doStuff(AbstractServer $o);
}
class ConcreteClient extends AbstractClient {
function doStuff(ConcreteServer $o) {}
}
?
This results in a fatal
Fatal error: Declaration of ConcreteClient::doStuff() must be compatible
with that of AbstractClient::doStuff() in
/Users/quickshiftin/gitRepos/timberline/php-api-v15-client/testOverride.php
on line 11
I was reading a few posts from way back when
http://marc.info/?t=10777490481r=1w=2
yet still find myself wondering. I think it can be said here that if
there's a contract defined by AbstractClient::doStuff, that same contract is
honored by ConcreteClient::doStuff. I also think changing the language to
support this notion wouldn't raise BC issues for the most part (at all?)
since at the moment you're forced to move to the lowest common denominator
in the tree, in this case
class ConcreteClient extends AbstractClient {
function doStuff(AbstractServer $o) {}
}
your feedback appreciated,
-nathan
