[PHP-DEV] Fw: small note about interface registration
I take it back, fixing that in SPL and reflection _did_ do something :) The only problem left now is that DL_UNLOAD's called too soon - we need ts_free_id() to be called in the Zend module_destructor, but DL_UNLOAD to be called at the end of tsrm_shutdown() - or at least, after the global core stuff is destroyed. And TSRM doesn't know about the module. Hm. - Original Message - From: "Steph Fox" <[EMAIL PROTECTED]> To: "internals" Sent: Sunday, June 04, 2006 8:26 AM Subject: small note about interface registration Guys/gal, At the risk of being boring, someone should probably know that the ZEND_ACC_INTERFACE flag isn't getting set for anything outside the Engine during zend_register_internal_interface(). zend_API.c needs to #include zend_compile.h to get it defined, unless you know a better way. SPL and Reflection don't use zend_register_internal_interface(), so they won't get theirs set from within ZE anyway (tho' they probably should). Note that this doesn't fix my PHP-GTK issue, it was just a side-query into global class table corruption :-( - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: small note about interface registration
Hello Steph, what did you fix in spl and reflection? best regards marcus Sunday, June 4, 2006, 9:05:02 AM, you wrote: > I take it back, fixing that in SPL and reflection _did_ do something :) > The only problem left now is that DL_UNLOAD's called too soon - we need > ts_free_id() to be called in the Zend module_destructor, but DL_UNLOAD to be > called at the end of tsrm_shutdown() - or at least, after the global core > stuff is destroyed. And TSRM doesn't know about the module. Hm. > - Original Message - > From: "Steph Fox" <[EMAIL PROTECTED]> > To: "internals" > Sent: Sunday, June 04, 2006 8:26 AM > Subject: small note about interface registration >> Guys/gal, >> >> At the risk of being boring, someone should probably know that the >> ZEND_ACC_INTERFACE flag isn't getting set for anything outside the Engine >> during zend_register_internal_interface(). zend_API.c needs to #include >> zend_compile.h to get it defined, unless you know a better way. >> >> SPL and Reflection don't use zend_register_internal_interface(), so they >> won't get theirs set from within ZE anyway (tho' they probably should). >> >> Note that this doesn't fix my PHP-GTK issue, it was just a side-query into >> global class table corruption :-( >> >> - Steph >> >> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Whichever way we go, the key would have to be either an integer or a
string (since that's what array indices can be), and going with an
integer here sounds like a really bad idea (chances of it colliding
with numeric indices are reasonably high on a 32-bit system). So if
we go with (a), it would definitely have to be a string as you
suggested. Not sure what's the best way to create a unique,
one-to-one mapped string representation of an object. If we can't
find a solution to that one, then it pretty much brings us to (b).
Zeev
At 03:57 04/06/2006, Andi Gutmans wrote:
Generally I think it's a good thing to allow to use objects as array indexes.
There are really two ways of doing it:
a) Try and find a way to create unique ideas.
b) Support __toString() and leave it up to the author.
I have a bit of a hard time finding a solution to (a) unless the
unique id is a string. Not that I think having it as a string is
necessarily a bad thing but I'd be interested in hearing what others think.
Supporting __toString() is the easiest way to go, especially as it
wouldn't lead to BC breaks. It would be up to the author to make
that a unique key like "Db#Person#1" but then they couldn't use
that with "print" because the value the class author would want
there would probably not be the one he'd want in array access.
Anyone got any thoughts, how bad of a break it would be if we did
create a unique id of objects, whether string or int? That's
something we probably could do for PHP 6 esp. if string is acceptable.
Andi
At 09:38 AM 6/3/2006, Marcus Boerger wrote:
Hello Andrew,
Saturday, June 3, 2006, 4:36:39 PM, you wrote:
> On Sat, Jun 03, 2006 at 01:42:12PM +0200, Marcus Boerger wrote:
>> Hello guys,
>>
>> the attached patch closes one more __toString() part. It allows
>> to use objects that define __toString as indexes to arrays. What do
>> you guys think about this, should we add it or stay with the old
>> behavior that didn't allow objects as indexes at all.
> Like others who have contributed to the thread I agree that it would be
> useful, but I think using __toString() wrong for this. There is a
> confusion two ideas here:
> 1. The string representation of an object, probably human
> readable, lucent string.
> 2. A unique hash of an object use to identify it programmatically,
> and likely unique. Probably a non-human friendly, opaque value.
> These are not the same thing. The latter is what, IMO, would be used
> for an objects value as an index into an array, not the former.
> The latter is available ... currently I do this like so:
> class a{ public function __toString() { return 'an object';}}
> $foo = new a;
> $bar = new a;
> $arr = new array()
> $arr[(string)$foo] = $foo; // The index is "Object id #1"
> $arr[(string)$bar] = $bar; // The index is "Object id #2"
> Note that the __tostring method is not used in the cast - a spearate
> issue, but needs to be pointed out for this issue.
> Therefore my suggested alternative to Marcus' patch is:
> When Objects are used in array index context, use the object ID or some
> variation. And, possibly, provide a magic method, or interface to
> generate an hash value of an object.
We cannot use the object id since that is not necessarily unique.
For the same reason SplObjectStorage cannot be done in userland.
However what you mention here is right. Other languages offer to
magic functions. A stringify one and a hashing one. But then again
i don't think we should add yet another magic feature.
best regards
marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: small note about interface registration
Not a lot (attached) - Original Message - From: "Marcus Boerger" <[EMAIL PROTECTED]> To: "Steph Fox" <[EMAIL PROTECTED]> Cc: "internals" Sent: Sunday, June 04, 2006 11:31 AM Subject: Re: [PHP-DEV] Fw: small note about interface registration Hello Steph, what did you fix in spl and reflection? best regards marcus Sunday, June 4, 2006, 9:05:02 AM, you wrote: I take it back, fixing that in SPL and reflection _did_ do something :) The only problem left now is that DL_UNLOAD's called too soon - we need ts_free_id() to be called in the Zend module_destructor, but DL_UNLOAD to be called at the end of tsrm_shutdown() - or at least, after the global core stuff is destroyed. And TSRM doesn't know about the module. Hm. - Original Message - From: "Steph Fox" <[EMAIL PROTECTED]> To: "internals" Sent: Sunday, June 04, 2006 8:26 AM Subject: small note about interface registration Guys/gal, At the risk of being boring, someone should probably know that the ZEND_ACC_INTERFACE flag isn't getting set for anything outside the Engine during zend_register_internal_interface(). zend_API.c needs to #include zend_compile.h to get it defined, unless you know a better way. SPL and Reflection don't use zend_register_internal_interface(), so they won't get theirs set from within ZE anyway (tho' they probably should). Note that this doesn't fix my PHP-GTK issue, it was just a side-query into global class table corruption :-( - Steph Best regards, Marcus __ NOD32 1.1380 (20060125) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com Index: ext/reflection/php_reflection.c === RCS file: /repository/php-src/ext/reflection/php_reflection.c,v retrieving revision 1.164.2.33.2.3 diff -u -r1.164.2.33.2.3 php_reflection.c --- ext/reflection/php_reflection.c 1 Jun 2006 14:31:22 - 1.164.2.33.2.3 +++ ext/reflection/php_reflection.c 4 Jun 2006 06:36:44 - @@ -4415,7 +4415,7 @@ reflection_ptr = zend_register_internal_class(&_reflection_entry TSRMLS_CC); INIT_CLASS_ENTRY(_reflection_entry, "Reflector", reflector_functions); - reflector_ptr = zend_register_internal_class(&_reflection_entry TSRMLS_CC); + reflector_ptr = zend_register_internal_interface(&_reflection_entry TSRMLS_CC); reflector_ptr->ce_flags = ZEND_ACC_ABSTRACT | ZEND_ACC_INTERFACE; INIT_CLASS_ENTRY(_reflection_entry, "ReflectionFunction", reflection_function_functions); Index: ext/spl/spl_functions.c === RCS file: /repository/php-src/ext/spl/spl_functions.c,v retrieving revision 1.28.2.3 diff -u -r1.28.2.3 spl_functions.c --- ext/spl/spl_functions.c 9 Mar 2006 11:43:45 - 1.28.2.3 +++ ext/spl/spl_functions.c 4 Jun 2006 06:37:34 - @@ -42,10 +42,10 @@ INIT_CLASS_ENTRY(ce, class_name, functions); ce.name_length = strlen(class_name); - *ppce = zend_register_internal_class(&ce TSRMLS_CC); + *ppce = zend_register_internal_interface(&ce TSRMLS_CC); /* entries changed by initialize */ - (*ppce)->ce_flags = ZEND_ACC_INTERFACE; + /* (*ppce)->ce_flags = ZEND_ACC_INTERFACE; */ } /* }}} */ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Missing __toString() part
In case we can't find a solution Andi's (a) approach, I think I like the explicit cast approach better than just implicitly converting to string. Rasmus pointed out that it's not clear why of all types PHP would implicitly convert the object to a string, and chances are that he's not the only person that will be surprised by that behavior. Zeev At 06:20 04/06/2006, Greg Beaver wrote: Marcus Boerger wrote: > Hello guys, > > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. I prefer to require an explicit (string) cast to use an object as an array index. The "can't use objects as array index" has actually helped me catch many subtle bugs that were slipping through in earlier PHP versions, I very much like this fatal error. I don't see this: $a = $b[$c]; being much clearer to understand than: $a = $b[$c]; or better yet $a = $b[$c->person()]; which is by far the clearest and easiest to debug (and results in a fatal error if $c is the wrong kind of object or the wrong string - even better for debugging) Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Rasmus, Andi,
first to Andi, there is no BC involved beside the fact that this would
allow objects being used in arrays which wasn't possible before.
Now a hashing value can easily be generated:
char * hash;
int len = spprintf(&hash,0,"%p:%d",Z_OBJ_HT_P(zobj),Z_OBJ_HANDLE_P(zobj));
That said maybe it is enough to add a generic hash function either the
engine or SPL:
/* {{{ proto string spl_object_hash(object obj)
Return hash id for given object */
PHP_FUNCTION(spl_object_hash)
{
zval *obj;
int len;
char *hash;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) ==
FAILURE) {
return;
}
len = spprintf(&hash, 0, "%p:%d", Z_OBJ_HT_P(obj), Z_OBJ_HANDLE_P(obj));
RETURN_STRINGL(hash, len, 0);
}
[EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'var_dump(spl_object_hash(new
stdClass));'
string(11) "0x87b6a40:1"
Maybe we want to scramble this with md5 or something alike:
/* {{{ proto string spl_object_hash(object obj)
Return hash id for given object */
PHP_FUNCTION(spl_object_hash)
{
zval *obj;
int len;
char *hash;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) ==
FAILURE) {
return;
}
len = spprintf(&hash, 0, "%p:%d", Z_OBJ_HT_P(obj), Z_OBJ_HANDLE_P(obj));
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, (unsigned char*)hash, len);
PHP_MD5Final(digest, &context);
make_digest(md5str, digest);
RETVAL_STRING(md5str, 1);
efree(hash);
}
[EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'var_dump(spl_object_hash(new
stdClass));'
string(32) "0bab1548e3b42acbcf1170617b5432ae"
For PHP 5.2 we could think about adding a hash handler to the object
handler table and provide the above as default implementation. That hash
handler would then be called when an object is being used as an offset.
Maybe later in PHP 6 we can also add an interface that allows to overload
that hash implementation. (If someone really wants that). Yet anything
the user can overload be it an interface or magic function (e.g. __hashOf)
seems to be too much for now.
Besides that i am meanwhile convinced that __toString shouldn't have to do
anything with objects as array offsets other then it can be requested by
the user thorugh a string cast (e.g.: $ar[(string)$obj]).
best regards
marcus
Sunday, June 4, 2006, 3:50:09 AM, you wrote:
> Alan Knowles wrote:
>>
>> $x = new Obj;
>> $y[$x]= 123;
>>
>> That behaviour is going to be fun to document, and for people unfamilar
>> with it to find in the manual
>> -> php.net/array -> go to array syntax page -> read down to find about
>> objects as keys -> go to __toHash() page...
>>
>> ..whereas...
>> $x = new Obj;
>> $y[$x->toHash()]= 123;
>>
>> they might have a chance to see instantly how that is supposed to work,
>> on the rare occasion that somebody needs this, is it really worth
>> building it into the langauge
> In that case, why not just use the existing __toString explicitly with:
>$x = new Obj;
>$y[(string)$x] = 123;
> This works today and basically gives you the same thing. The only thing
> it doesn't do is separate an array index context from an output context
> allowing you do different things in the two cases.
> I think if we are going to add a toHash thing, it should trigger when
> the object is used in a hash context, just like toString triggers when
> it is used in a string context.
> -Rasmus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Missing __toString() part
Marcus Boerger wrote: Hello guys, the attached patch closes one more __toString() part. It allows to use objects that define __toString as indexes to arrays. What do you guys think about this, should we add it or stay with the old behavior that didn't allow objects as indexes at all. -1 on automatic __toString() +1 on explicit (string) cast (as it is now) +0 on __toHash()/__toKey() (which must be implemented explicitly) Rasmus' idea of changing the HashKey is... duh... at least something to think some more time about. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src / README.NEW-OUTPUT-API
Andi Gutmans wrote: Can you give a short summary of what the essence of the change is and how the APIs have changed (Both the ones available to the PHP developer and to the extension writer?) To come back to that topic; there are certainly some implications to think about, some of the top of my head for the PHP developer: To my understanding the effect of the chunk size never worked the way like documented, at least not the last few months or even years. Currently (new code) as soon as the chunk_size is reached, the output handler will be started and all data currently available will be passed through it. The array returned by ob_get_status() changed. There are some new features not available to the user land like flushing the whole output handler stack. I'm not sure if we should provide this functionality. Same thing goes for the output handler hook; we might provide user land API for that but if the coder is going to use an object or resource as handler context we'll see once a again the destructor chicken and egg problem on shutdown. I always found the user land API (function names) a bit weird but changing it is probably out of question? Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC array functions
Hi, Took from Java world, it could be something like array_has_next() which is more significant because return boolean is only about the next value not about all the next values. On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: Hello Andi, Wednesday, May 31, 2006, 5:28:47 AM, you wrote: > Zeev and I designed each() to deprecate key()/current()/etc. which > came from PHP/FI 2. Maybe not exactly what you're looking for but > just want to point out that there have always been some issues with > the latter functions. > If each() isn't suitable (and/or you want something quicker) than I'm > OK with an array_* function but I don't like array_valid(). It sounds > too much like is_array() and implies the array is valid. Maybe > something like array_valid_position()? Also good, i just chose the name becuase it's close to Iterator::valid(). I am however more interested in the array_has_more() thingie. Often enough one runs into a problem where the last entry of a list has a slightly different behavior. > At 02:52 PM 5/27/2006, Marcus Boerger wrote: >>Hello Matthew, >> >>Saturday, May 27, 2006, 11:36:16 PM, you wrote: >> >> > Pierre wrote: >> >> On 5/27/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> >>> - bool array(array $array) >> >>> >> >>> cehcks whether arra position is valid (e.g. like "key($array) !== >> >>> NULL") >> >> >> >> I don't understand this one. >> >> >> >> > I think you have to listen to psychedelic music and take a hit of >> LSD first. >> >>Actually the point is that you cannot simply do stuff like >>"while(key($array))". And "while(key($array) != 0)" doesn't work either. >>Also "if (!key($array))" is probably different from what you expect. >>And of course "isset(key($array))" doens't work either. >> >>Best regards, >> Marcus >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC array functions
Hello Eric, our iterators have next() and valid() in separate functions. That alone makes them way more powerful then java' iterators. In SPL we have an iterator wrapper called CachingIterator that has a method has_more() which has a boolean return value that allows to check whether a call to next() leaves the iterator valid or not. So changing the name would only add confusion. best regards marcus Sunday, June 4, 2006, 1:17:55 PM, you wrote: > Hi, > Took from Java world, it could be something like array_has_next() which is > more significant because return boolean is only about the next value not > about all the next values. > On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> >> Hello Andi, >> >> Wednesday, May 31, 2006, 5:28:47 AM, you wrote: >> >> > Zeev and I designed each() to deprecate key()/current()/etc. which >> > came from PHP/FI 2. Maybe not exactly what you're looking for but >> > just want to point out that there have always been some issues with >> > the latter functions. >> > If each() isn't suitable (and/or you want something quicker) than I'm >> > OK with an array_* function but I don't like array_valid(). It sounds >> > too much like is_array() and implies the array is valid. Maybe >> > something like array_valid_position()? >> >> Also good, i just chose the name becuase it's close to Iterator::valid(). >> I am however more interested in the array_has_more() thingie. Often enough >> one runs into a problem where the last entry of a list has a slightly >> different behavior. >> >> > At 02:52 PM 5/27/2006, Marcus Boerger wrote: >> >>Hello Matthew, >> >> >> >>Saturday, May 27, 2006, 11:36:16 PM, you wrote: >> >> >> >> > Pierre wrote: >> >> >> On 5/27/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> >> >>> - bool array(array $array) >> >> >>> >> >> >>> cehcks whether arra position is valid (e.g. like "key($array) !== >> >> >>> NULL") >> >> >> >> >> >> I don't understand this one. >> >> >> >> >> >> >> > I think you have to listen to psychedelic music and take a hit of >> >> LSD first. >> >> >> >>Actually the point is that you cannot simply do stuff like >> >>"while(key($array))". And "while(key($array) != 0)" doesn't work either. >> >>Also "if (!key($array))" is probably different from what you expect. >> >>And of course "isset(key($array))" doens't work either. >> >> >> >>Best regards, >> >> Marcus >> >> >> >>-- >> >>PHP Internals - PHP Runtime Development Mailing List >> >>To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> Best regards, >> Marcus >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC array functions
Hello Eric again, forget the last mail, you're right it is hasNext() in php, too. So it should be array_has_next() as well. Thanks to michael for reminding me. I got confused with the original implementation (i shouldn't have changed the name). best regards marcus Sunday, June 4, 2006, 1:39:04 PM, you wrote: > Hello Eric, > our iterators have next() and valid() in separate functions. That alone > makes them way more powerful then java' iterators. In SPL we have an > iterator wrapper called CachingIterator that has a method has_more() > which has a boolean return value that allows to check whether a call to > next() leaves the iterator valid or not. So changing the name would only > add confusion. > best regards > marcus > Sunday, June 4, 2006, 1:17:55 PM, you wrote: >> Hi, >> Took from Java world, it could be something like array_has_next() which is >> more significant because return boolean is only about the next value not >> about all the next values. >> On 6/3/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: >>> >>> Hello Andi, >>> >>> Wednesday, May 31, 2006, 5:28:47 AM, you wrote: >>> >>> > Zeev and I designed each() to deprecate key()/current()/etc. which >>> > came from PHP/FI 2. Maybe not exactly what you're looking for but >>> > just want to point out that there have always been some issues with >>> > the latter functions. >>> > If each() isn't suitable (and/or you want something quicker) than I'm >>> > OK with an array_* function but I don't like array_valid(). It sounds >>> > too much like is_array() and implies the array is valid. Maybe >>> > something like array_valid_position()? >>> >>> Also good, i just chose the name becuase it's close to Iterator::valid(). >>> I am however more interested in the array_has_more() thingie. Often enough >>> one runs into a problem where the last entry of a list has a slightly >>> different behavior. >>> >>> > At 02:52 PM 5/27/2006, Marcus Boerger wrote: >>> >>Hello Matthew, >>> >> >>> >>Saturday, May 27, 2006, 11:36:16 PM, you wrote: >>> >> >>> >> > Pierre wrote: >>> >> >> On 5/27/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: >>> >> >>> - bool array(array $array) >>> >> >>> >>> >> >>> cehcks whether arra position is valid (e.g. like "key($array) !== >>> >> >>> NULL") >>> >> >> >>> >> >> I don't understand this one. >>> >> >> >>> >> >>> >> > I think you have to listen to psychedelic music and take a hit of >>> >> LSD first. >>> >> >>> >>Actually the point is that you cannot simply do stuff like >>> >>"while(key($array))". And "while(key($array) != 0)" doesn't work either. >>> >>Also "if (!key($array))" is probably different from what you expect. >>> >>And of course "isset(key($array))" doens't work either. >>> >> >>> >>Best regards, >>> >> Marcus >>> >> >>> >>-- >>> >>PHP Internals - PHP Runtime Development Mailing List >>> >>To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >>> >>> >>> Best regards, >>> Marcus >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> > Best regards, > Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello, > Hello Rasmus, Andi, > [EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'var_dump(spl_object_hash(new > stdClass));' string(32) "0bab1548e3b42acbcf1170617b5432ae" > > For PHP 5.2 we could think about adding a hash handler to the object > handler table and provide the above as default implementation. That > hash handler would then be called when an object is being used as an > offset. Maybe later in PHP 6 we can also add an interface that allows > to overload that hash implementation. (If someone really wants that). > Yet anything the user can overload be it an interface or magic > function (e.g. __hashOf) seems to be too much for now. Do you mean to allow object as indices with this default implementation? But this implementataion cannot be overloaded? I fail to see the needs of such things in 5.x (or 6.x even with overload). Adding another magic method __toHash is also not what I would like. Adding a function hash_from_object() or spl_hash_from object() to ease the generations of hashes is indeed a good idea. There is no impact in the objects managements and people are free to use it or not (no magic default behaviors). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Missing __toString() part
On Sun, 4 Jun 2006, Michael Wallner wrote: > Marcus Boerger wrote: > > Hello guys, > > > > the attached patch closes one more __toString() part. It allows > > to use objects that define __toString as indexes to arrays. What do > > you guys think about this, should we add it or stay with the old > > behavior that didn't allow objects as indexes at all. > > -1 on automatic __toString() > +1 on explicit (string) cast (as it is now) > +0 on __toHash()/__toKey() (which must be implemented explicitly) I changed my mind :) -1 on automatic __toString() +1 on explicit (string) cast -1 on __toHash/__toKey +1 on unique object identifiers regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Pierre, Sunday, June 4, 2006, 1:52:41 PM, you wrote: > Hello, >> Hello Rasmus, Andi, >> [EMAIL PROTECTED] /usr/src/PHP_5_2 $ php -r 'var_dump(spl_object_hash(new >> stdClass));' string(32) "0bab1548e3b42acbcf1170617b5432ae" >> >> For PHP 5.2 we could think about adding a hash handler to the object >> handler table and provide the above as default implementation. That >> hash handler would then be called when an object is being used as an >> offset. Maybe later in PHP 6 we can also add an interface that allows >> to overload that hash implementation. (If someone really wants that). >> Yet anything the user can overload be it an interface or magic >> function (e.g. __hashOf) seems to be too much for now. > Do you mean to allow object as indices with this default > implementation? But this implementataion cannot be overloaded? I fail > to see the needs of such things in 5.x (or 6.x even with overload). > Adding another magic method __toHash is also not what I would like. > Adding a function hash_from_object() or spl_hash_from object() to ease > the generations of hashes is indeed a good idea. There is no impact in > the objects managements and people are free to use it or not (no magic > default behaviors). Hence i wrote "For PHP 5.2 we **could** think"... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On 6/4/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: > Adding a function hash_from_object() or spl_hash_from object() to ease > the generations of hashes is indeed a good idea. There is no impact in > the objects managements and people are free to use it or not (no magic > default behaviors). Hence i wrote "For PHP 5.2 we **could** think"... Yes, and what's the point of this answer? You should have read my mail as: -1 for any magic changes +1 to keep $a[(string)$o] -1 for __toHash/whatever will be the name of this method +0 for an extra (and extern) function to get an unique hash of an object --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: MFHing zend_fcall_info_*() to 5.2
Hello Dmitry,
the 'f' requires at least the first helper, so it makes sense to have
all three of them in the engine. Attached you will find the patch for
the helpers and the 'f' thingie for 5.2 and an additional patch for SPL
to introduce iterator_apply() which uses the stuff.
marcus
Wednesday, May 31, 2006, 12:46:59 PM, you wrote:
> Hmm,
> Seems 'f' really make sense for simplification.
> I am not sure about other helpers.
> I'll need to review patch once again.
> Could you include some use-cases (SPL patch that uses this one)?
> Thanks. Dmitry.
>> -Original Message-
>> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, May 31, 2006 12:19 PM
>> To: Dmitry Stogov; internals@lists.php.net
>> Cc: [EMAIL PROTECTED]; 'Andi Gutmans'; Zeev Suraski
>> Subject: Re: MFHing zend_fcall_info_*() to 5.2
>>
>>
>> Hello Dmitry,
>>
>> my patch doesn't change anything. If just adds stuff that
>> deals with defined functions only. If now you want to support
>> all functions that can be defined later it wouldn't work this
>> way (1). Actually it would require parsing the zval and
>> checking whether it might get callable in some future. While
>> this is the right solution for error handlers it is not the
>> right way for stuff like callback in array and SPL functions.
>> Once those are called the callback is used hence there is no
>> way it can suddenly come out of nowhere. My patch now
>> adresses this in a way that is much more efficient than doing
>> a two phase approach.
>>
>> best regards
>> marcus
>>
>> (1) I experiemened with 'F' parsing that only verified if
>> something might get callable at some point. Though that
>> worked it was unneccessary slow for the intended purpose.
>>
>> Wednesday, May 31, 2006, 8:29:01 AM, you wrote:
>>
>> > Hi Marcus,
>>
>> > We discussed the patch.
>>
>> > Several notes:
>> > PHP allowed pass callback function or method that is not
>> defined yet.
>> > Your patch disallows this.
>>
>> > > > some_internal_func("foo");
>> > eval("function foo() {}");
>> ?>>
>>
>> > Usage of default values for functions will be problematic
>> with it. I
>> > don't think that we really need special case for 'callback'
>> afguments.
>> > (It would be good for strong-typed language).
>>
>> > According to helpers, I would like suggest to add them into SPL
>> > itself and don't overload ZE.
>>
>> I can do so but don't see sense in doing so.
>>
>> best regards
>> marcus
>>
>> >> >Date: Sat, 27 May 2006 22:32:13 +0200
>> >> >From: Marcus Boerger <[EMAIL PROTECTED]>
>> >> >Reply-To: Marcus Boerger <[EMAIL PROTECTED]>
>> >> >To: Andi Gutmans <[EMAIL PROTECTED]>, Zeev Suraski <[EMAIL PROTECTED]>,
>> >> > Ilia Alshanetsky <[EMAIL PROTECTED]>
>> >> >Cc: internals@lists.php.net
>> >> >Subject: MFHing zend_fcall_info_*() to 5.2
>> >> >X-Bogosity: No, tests=bogofilter, spamicity=0.000475,
>> version=0.92.8
>> >> >
>> >> >Hello Andi, Zeev, Ilia,
>> >> >
>> >> > the attached patch adds three new functions that make calling
>> >> >functions a lot easier - at least for me in SPL. And it also
>> >> does a few
>> >> >things correct which are probably overseen easily. The
>> >> addition works
>> >> >in HEAD already and paases all memcheck tests idid so far.
>>
>>
>>
>>
Best regards,
MarcusIndex: ext/spl/php_spl.c
===
RCS file: /repository/php-src/ext/spl/php_spl.c,v
retrieving revision 1.52.2.28.2.1
diff -u -p -d -r1.52.2.28.2.1 php_spl.c
--- ext/spl/php_spl.c 4 Jun 2006 10:47:22 - 1.52.2.28.2.1
+++ ext/spl/php_spl.c 4 Jun 2006 11:18:11 -
@@ -610,7 +610,14 @@ PHP_MINFO_FUNCTION(spl)
static
ZEND_BEGIN_ARG_INFO(arginfo_iterator, 0)
- ZEND_ARG_INFO(0, iterator)
+ ZEND_ARG_OBJ_INFO(0, iterator, Traversable, 0)
+ZEND_END_ARG_INFO();
+
+static
+ZEND_BEGIN_ARG_INFO_EX(arginfo_iterator_apply, 0, 0, 2)
+ ZEND_ARG_OBJ_INFO(0, iterator, Traversable, 0)
+ ZEND_ARG_INFO(0, function)
+ ZEND_ARG_ARRAY_INFO(0, args, 1)
ZEND_END_ARG_INFO();
/* {{{ spl_functions
@@ -628,6 +635,7 @@ zend_function_entry spl_functions[] = {
#ifdef SPL_ITERATORS_H
PHP_FE(iterator_to_array, arginfo_iterator)
PHP_FE(iterator_count, arginfo_iterator)
+ PHP_FE(iterator_apply, arginfo_iterator_apply)
#endif /* SPL_ITERATORS_H */
{NULL, NULL, NULL}
};
Index: ext/spl/spl_iterators.c
===
RCS file: /repository/php-src/ext/spl/spl_iterators.c,v
retrieving revision 1.73.2.30.2.9
diff -u -p -d -r1.73.2.30.2.9 spl_iterators.c
--- ext/spl/spl_iterators.c 21 May 2006 18:13:37 - 1.73.2.30.2.9
+++ ext/spl/spl_iterators.c 4 Jun 2006 11:18:12 -
@@ -2612,6 +2612,54 @@ PHP_FUNCTION(iterator_count)
}
/* }}} */
+typedef struct {
+ zval *obj;
+ zval *args;
+ long coun
Re: [PHP-DEV] Missing __toString() part
Hello Pierre, Sunday, June 4, 2006, 2:05:52 PM, you wrote: > On 6/4/06, Marcus Boerger <[EMAIL PROTECTED]> wrote: >> Adding a function hash_from_object() or spl_hash_from object() to ease >> > the generations of hashes is indeed a good idea. There is no impact in >> > the objects managements and people are free to use it or not (no magic >> > default behaviors). >> >> Hence i wrote "For PHP 5.2 we **could** think"... > Yes, and what's the point of this answer? You reply didn't sound like you understood what i wrote. Having a vote from you makes your thoughts clear also i got it like that already. And just in case anybody is interested in my voting: ~0 for any magic changes ~0 for __toHash/whatever will be the name of this method +1 to keep $a[(string)$o] +1 for an extra (and extern) function to get an unique hash of an object -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
I would suggest : a) Make sure $arr[(string)$obj] works (I see no reason for it not to). b) Look into how to support a unique identifier (-1 on a hash value). Two main questions are how this thing looks like, and whether it's explicit (you need to call some function/method to get it) or implicit (e.g. $arr[$obj]). A Unique indentifier could look something like "Classname#Object id" e.g. "SimpleXMLElement#1". Andi P.S.-Yep, sticking to bullets keeps emails brief :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On 4-Jun-06, at 10:26 AM, Andi Gutmans wrote: I would suggest : a) Make sure $arr[(string)$obj] works (I see no reason for it not to). It already does, nothing needs to be changed or added. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Andi, the classname has not make the id unique. In fact it has nothing to do with a hash. best regards marcus Sunday, June 4, 2006, 4:26:13 PM, you wrote: > I would suggest : > a) Make sure $arr[(string)$obj] works (I see no reason for it not to). > b) Look into how to support a unique identifier (-1 on a hash value). > Two main questions are how this thing looks like, and whether it's > explicit (you need to call some function/method to get it) or > implicit (e.g. $arr[$obj]). > A Unique indentifier could look something like "Classname#Object id" > e.g. "SimpleXMLElement#1". > Andi > P.S.-Yep, sticking to bullets keeps emails brief :) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
What extensions today have different objects with the same object ids (inside a certain class)? What do you mean it has nothing to do with hash? Don't understand what you mean. At 07:56 AM 6/4/2006, Marcus Boerger wrote: Hello Andi, the classname has not make the id unique. In fact it has nothing to do with a hash. best regards marcus Sunday, June 4, 2006, 4:26:13 PM, you wrote: > I would suggest : > a) Make sure $arr[(string)$obj] works (I see no reason for it not to). > b) Look into how to support a unique identifier (-1 on a hash value). > Two main questions are how this thing looks like, and whether it's > explicit (you need to call some function/method to get it) or > implicit (e.g. $arr[$obj]). > A Unique indentifier could look something like "Classname#Object id" > e.g. "SimpleXMLElement#1". > Andi > P.S.-Yep, sticking to bullets keeps emails brief :) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Andi, it was your own argument that the id itself is not unique when some time ago somebody wanted to have access to that id from userland. And it is also the reason for SplObjectStorage the way it is today. By 'it hash' nothing to do with hash' i mean that the classname does not belong into a hash. best regards marcus Sunday, June 4, 2006, 4:58:34 PM, you wrote: > What extensions today have different objects with the same object ids > (inside a certain class)? > What do you mean it has nothing to do with hash? Don't understand > what you mean. > At 07:56 AM 6/4/2006, Marcus Boerger wrote: >>Hello Andi, >> >> the classname has not make the id unique. In fact it has nothing to >>do with a hash. >> >>best regards >>marcus >> >>Sunday, June 4, 2006, 4:26:13 PM, you wrote: >> >> > I would suggest : >> > a) Make sure $arr[(string)$obj] works (I see no reason for it not to). >> > b) Look into how to support a unique identifier (-1 on a hash value). >> > Two main questions are how this thing looks like, and whether it's >> > explicit (you need to call some function/method to get it) or >> > implicit (e.g. $arr[$obj]). >> >> > A Unique indentifier could look something like "Classname#Object id" >> > e.g. "SimpleXMLElement#1". >> >> > Andi >> >> > P.S.-Yep, sticking to bullets keeps emails brief :) >> >> >> >> >>Best regards, >> Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
At 08:08 AM 6/4/2006, Marcus Boerger wrote: Hello Andi, it was your own argument that the id itself is not unique when some time ago somebody wanted to have access to that id from userland. And it is also the reason for SplObjectStorage the way it is today. The object id itself is not unique, but coupled with the class name it is. All this means is that the unique id has to be a string and not a number. I mentioned in the past that it'd be a problem to have a number as the unique id. By 'it hash' nothing to do with hash' i mean that the classname does not belong into a hash. My point is that the string "ClassName#id" is what would be the unique identifier. e.g. that's what toKey() would return (assuming we'd want such a method). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Andi, the classname doesn't help, it is the handler that you need. In theory you can have two objects with the same id and classname but not with the same id and handler table. best regards marcus Sunday, June 4, 2006, 5:14:46 PM, you wrote: > At 08:08 AM 6/4/2006, Marcus Boerger wrote: >>Hello Andi, >> >> it was your own argument that the id itself is not unique when some >>time ago somebody wanted to have access to that id from userland. And >>it is also the reason for SplObjectStorage the way it is today. > The object id itself is not unique, but coupled with the class name > it is. All this means is that the unique id has to be a string and > not a number. I mentioned in the past that it'd be a problem to have > a number as the unique id. >>By 'it hash' nothing to do with hash' i mean that the classname does >>not belong into a hash. > My point is that the string "ClassName#id" is what would be the > unique identifier. e.g. that's what toKey() would return (assuming > we'd want such a method). > Andi Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
MB>> the classname doesn't help, it is the handler that you need. In MB>>theory you can have two objects with the same id and classname but not MB>>with the same id and handler table. Yes, theoretically you could have two modules returning same class names for their objects, though it would be extremely bad practice to do it. Bigger problem is, however, that object handler doesn't really have to give you any meaningful class name at all - for all it worth it can always return something like "No class name". -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Yes, I realize that but it doesn't happen today and I don't think we couldn't make this a rule (requiring extensions to have unique id's per classes). In any case, we can always make it the following string: "id=#unique id" Andi At 08:18 AM 6/4/2006, Marcus Boerger wrote: Hello Andi, the classname doesn't help, it is the handler that you need. In theory you can have two objects with the same id and classname but not with the same id and handler table. best regards marcus Sunday, June 4, 2006, 5:14:46 PM, you wrote: > At 08:08 AM 6/4/2006, Marcus Boerger wrote: >>Hello Andi, >> >> it was your own argument that the id itself is not unique when some >>time ago somebody wanted to have access to that id from userland. And >>it is also the reason for SplObjectStorage the way it is today. > The object id itself is not unique, but coupled with the class name > it is. All this means is that the unique id has to be a string and > not a number. I mentioned in the past that it'd be a problem to have > a number as the unique id. >>By 'it hash' nothing to do with hash' i mean that the classname does >>not belong into a hash. > My point is that the string "ClassName#id" is what would be the > unique identifier. e.g. that's what toKey() would return (assuming > we'd want such a method). > Andi Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
At 08:22 AM 6/4/2006, Stanislav Malyshev wrote: MB>> the classname doesn't help, it is the handler that you need. In MB>>theory you can have two objects with the same id and classname but not MB>>with the same id and handler table. Yes, theoretically you could have two modules returning same class names for their objects, though it would be extremely bad practice to do it. Bigger problem is, however, that object handler doesn't really have to give you any meaningful class name at all - for all it worth it can always return something like "No class name". We should probably make this a requirement and I don't know of one today that doesn't have an associated class name. I believe some parts of PHP might blow up if this isn't supported. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Andi, you don't read my proposals, do you? If you read them you will find that i actually proposed to add a function that uses exactly what you just wrote here. best regards marcus Sunday, June 4, 2006, 5:35:25 PM, you wrote: > Yes, I realize that but it doesn't happen today and I don't think we > couldn't make this a rule (requiring extensions to have unique id's > per classes). In any case, we can always make it the following string: > "id=#unique id" > Andi > At 08:18 AM 6/4/2006, Marcus Boerger wrote: >>Hello Andi, >> >> the classname doesn't help, it is the handler that you need. In theory >>you can have two objects with the same id and classname but not with the >>same id and handler table. >> >>best regards >>marcus >> >>Sunday, June 4, 2006, 5:14:46 PM, you wrote: >> >> > At 08:08 AM 6/4/2006, Marcus Boerger wrote: >> >>Hello Andi, >> >> >> >> it was your own argument that the id itself is not unique when some >> >>time ago somebody wanted to have access to that id from userland. And >> >>it is also the reason for SplObjectStorage the way it is today. >> >> > The object id itself is not unique, but coupled with the class name >> > it is. All this means is that the unique id has to be a string and >> > not a number. I mentioned in the past that it'd be a problem to have >> > a number as the unique id. >> >> >>By 'it hash' nothing to do with hash' i mean that the classname does >> >>not belong into a hash. >> >> > My point is that the string "ClassName#id" is what would be the >> > unique identifier. e.g. that's what toKey() would return (assuming >> > we'd want such a method). >> >> > Andi >> >> >> >> >>Best regards, >> Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On Sun, 4 Jun 2006, Andi Gutmans wrote: > Yes, I realize that but it doesn't happen today and I don't think we couldn't > make this a rule (requiring extensions to have unique id's per classes). In > any case, we can always make it the following string: > "id=#unique id" And that is exactly what Marcus already suggested: char * hash; int len = spprintf(&hash,0,"%p:%d",Z_OBJ_HT_P(zobj),Z_OBJ_HANDLE_P(zobj)); regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
AG>>We should probably make this a requirement and I don't know of one AG>>today that doesn't have an associated class name. I believe some parts AG>>of PHP might blow up if this isn't supported. There are parts that can blow up if get_class_name is NULL or returns NULL (though good practice would be to filter such places out but I'm not sure it was ever accomplished) - however it doesn't have to be NULL to be a problem. Imagine two extensions that bridge external objects - e.g., Java and .Net one - that attempt to return real class of an object, but if it doesn't succeed (e.g., internal reflection doesn't work for some reason) they return "???" instead. It's not that good, but we can't catch it and we can't even put up a requirement out saying "your 'don't know' value should be different from other's" - how's one supposed to know what other's value is? And if you don't do something very unrelated would break in very strange ways - so it's be quite hard even point to what is the cause. So in fact classname here would not be a good idea for ID. Handler table, however, combined with object handle seems to be good way to ID an object - it's how the engine identifies them after all... -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Stanislav,
do you remember any reason why we have the current layout with the zval
pointing to a handler and that having a function which returns a pointer
to the class_entry as well as a function that returns the name?
struct _zend_object_handlers {
[...]
zend_object_get_class_entry_t get_class_entry;
zend_object_get_class_name_tget_class_name;
typedef struct _zend_object_value {
zend_object_handle handle;
zend_object_handlers *handlers;
} zend_object_value;
And wouldn't it be faster to drop both handlers from the table and
instead have zend_object_value have a pointer to zend_class_entry
and that a pounter to the handler table?
best regards
marcus
Sunday, June 4, 2006, 5:42:02 PM, you wrote:
AG>>>We should probably make this a requirement and I don't know of one
AG>>>today that doesn't have an associated class name. I believe some parts
AG>>>of PHP might blow up if this isn't supported.
> There are parts that can blow up if get_class_name is NULL or returns NULL
> (though good practice would be to filter such places out but I'm not sure
> it was ever accomplished) - however it doesn't have to be NULL to be a
> problem. Imagine two extensions that bridge external objects - e.g., Java
> and .Net one - that attempt to return real class of an object, but if it
> doesn't succeed (e.g., internal reflection doesn't work for some reason)
> they return "???" instead. It's not that good, but we can't catch it and
> we can't even put up a requirement out saying "your 'don't know' value
> should be different from other's" - how's one supposed to know what
> other's value is? And if you don't do something very unrelated would break
> in very strange ways - so it's be quite hard even point to what is the
> cause.
> So in fact classname here would not be a good idea for ID. Handler table,
> however, combined with object handle seems to be good way to ID an object
> - it's how the engine identifies them after all...
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
MB>>typedef struct _zend_object_value {
MB>>zend_object_handle handle;
MB>>zend_object_handlers *handlers;
MB>>} zend_object_value;
MB>>
MB>>And wouldn't it be faster to drop both handlers from the table and
MB>>instead have zend_object_value have a pointer to zend_class_entry
MB>>and that a pounter to the handler table?
Not quite - since not all objects have zend_class_entry for them so you
couldn't actually use it - unless you insert check each time _and_ write
code to handle _both_ cases - using zend_class_entry pointer and using
something else - so it's actually easier to do the right thing from the
start and use the handlers. Of course, you could "optimize" it for the
case zend_class_entry exists and add the zend_class_entry field into the
object value - but IMHO the resulting code and model complication would do
much more harm than speed improvement on saving one function call (which
I'm not sure is of any significance). Also, this would inevitably lead to
creating code which forgets to use handlers and breaks in all kinds of
funny ways on overloaded objects. My opinion is that it is better to have
one consistent API.
As for the question why there are two handlers - because class name is
useful in all kinds of contexts like backtaces, exceptions, messages, etc.
even though you may not have zend_class_entry - so it's a possibility for
the overloaded object to give maximum iformation there.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Again, I don't think we should have a hash but a unique id which can be used as an array key and in other things. Difference. Hash implies that it's not unique, I'm talking about unique. So yes, I'd take the starting point of Marcus' proposal but: a) Make the value start with a letter so that this isn't autoconverted but taken as a literal string key. Again, something like "id=%p:%d" b) Not call it hash because I see this as a unique id and not as a hash value which is not unique necessarily. c) This should be something outside SPL and part of the engine. Question is again, whether it's explicit or implicit (back to the question I had earlier). Do you just want to add a function which returns this thing or do you want $arr[$obj] to automatically ask for it. These are valid questions and should be answered. Andi At 08:41 AM 6/4/2006, Derick Rethans wrote: On Sun, 4 Jun 2006, Andi Gutmans wrote: > Yes, I realize that but it doesn't happen today and I don't think we couldn't > make this a rule (requiring extensions to have unique id's per classes). In > any case, we can always make it the following string: > "id=#unique id" And that is exactly what Marcus already suggested: char * hash; int len = spprintf(&hash,0,"%p:%d",Z_OBJ_HT_P(zobj),Z_OBJ_HANDLE_P(zobj)); regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On Sun, 4 Jun 2006, Andi Gutmans wrote: > Again, I don't think we should have a hash but a unique id which can be used > as an array key and in other things. Difference. Hash implies that it's not > unique, I'm talking about unique. Instead of all those hacky ways to come up with IDs, why don't se simply change the engine not to reuse those IDs in the first place? Seems to solve quite a few problems. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
At 09:05 AM 6/4/2006, Derick Rethans wrote: On Sun, 4 Jun 2006, Andi Gutmans wrote: > Again, I don't think we should have a hash but a unique id which can be used > as an array key and in other things. Difference. Hash implies that it's not > unique, I'm talking about unique. Instead of all those hacky ways to come up with IDs, why don't se simply change the engine not to reuse those IDs in the first place? Seems to solve quite a few problems. Because the idea is that each extension can control its own object storage if needed. If it gets a centralized id with an arbitrary limit (say 32bit) then they'd all have to use hashes for the storage instead of arrays. It's actually a beneficial thing that we decoupled the extensions. There is no reason why a string key such as I suggested, wouldn't solve your problems of lack of id... Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Hello Stanislav,
ok, that was good explanation, thanks.
best regards
marcus
Sunday, June 4, 2006, 6:02:33 PM, you wrote:
MB>>>typedef struct _zend_object_value {
MB>>>zend_object_handle handle;
MB>>>zend_object_handlers *handlers;
MB>>>} zend_object_value;
MB>>>
MB>>>And wouldn't it be faster to drop both handlers from the table and
MB>>>instead have zend_object_value have a pointer to zend_class_entry
MB>>>and that a pounter to the handler table?
> Not quite - since not all objects have zend_class_entry for them so you
> couldn't actually use it - unless you insert check each time _and_ write
> code to handle _both_ cases - using zend_class_entry pointer and using
> something else - so it's actually easier to do the right thing from the
> start and use the handlers. Of course, you could "optimize" it for the
> case zend_class_entry exists and add the zend_class_entry field into the
> object value - but IMHO the resulting code and model complication would do
> much more harm than speed improvement on saving one function call (which
> I'm not sure is of any significance). Also, this would inevitably lead to
> creating code which forgets to use handlers and breaks in all kinds of
> funny ways on overloaded objects. My opinion is that it is better to have
> one consistent API.
> As for the question why there are two handlers - because class name is
> useful in all kinds of contexts like backtaces, exceptions, messages, etc.
> even though you may not have zend_class_entry - so it's a possibility for
> the overloaded object to give maximum iformation there.
> --
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Andi Gutmans wrote:
Again, I don't think we should have a hash but a unique id which can be
used as an array key and in other things. Difference. Hash implies that
it's not unique, I'm talking about unique. So yes, I'd take the starting
point of Marcus' proposal but:
a) Make the value start with a letter so that this isn't autoconverted
but taken as a literal string key. Again, something like "id=%p:%d"
b) Not call it hash because I see this as a unique id and not as a hash
value which is not unique necessarily.
c) This should be something outside SPL and part of the engine. Question
is again, whether it's explicit or implicit (back to the question I had
earlier). Do you just want to add a function which returns this thing or
do you want $arr[$obj] to automatically ask for it.
These are valid questions and should be answered.
I think if we implement a way to get a hash from an object, or at least
a unique identifier that can be used as a hash, then it should be
implicit just like other things are implicitly converted when the
context is clear. Of course, you should also be able to force it
explicitly. And I don't think there is any point in doing this unless
we also implicitly go the other way. From unique identifier to object.
As in:
class foo { function bar($arg) { echo $arg; } }
$obj1 = new foo;
$obj2 = new foo;
$a = array($obj1=>1,$obj2=>2);
foreach($a as $k=>$v) {
$k->bar($v);
}
Unless this works, I am not sure there is any point to all this. To me
the end goal is to make it possible to use types other than strings and
numbers as array indices which to me also means we should look at doing
the same for arrays.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
There will be a BC problem with classes implementing ArrayAccess where the array key is passed to offsetXXX methods as it is. And there we have objects also allowed as parameters. 2006/6/3, Marcus Boerger <[EMAIL PROTECTED]>: Hello guys, the attached patch closes one more __toString() part. It allows to use objects that define __toString as indexes to arrays. What do you guys think about this, should we add it or stay with the old behavior that didn't allow objects as indexes at all. -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
I am sorry if I missed the whole thread. I think that using the result of __toString() for indexing objects is a bad idea. If we want to allow this behavior (which is actually useful in some situations), I'd rather we had a __hash() method or something similar to what Python does. The string representation of the object and its hashed representation may be very different. -Andrei On Jun 3, 2006, at 4:42 AM, Marcus Boerger wrote: Hello guys, the attached patch closes one more __toString() part. It allows to use objects that define __toString as indexes to arrays. What do you guys think about this, should we add it or stay with the old behavior that didn't allow objects as indexes at all. -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- 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
Re: [PHP-DEV] [RFC] E_STRICT
On Wed, May 31, 2006 at 06:24:35PM +0400, Antony Dovgal wrote: > > So that E_STRICT notices introduced in 6.x will become E_FATALs only in 7.0 > and so on. That's pretty much what I was going to say. To be clear, unlike the commit that was recently reverted, E_STRICT should never be moved into E_ALL. What should change is the type of error the behaviors trigger. So, something from PHP 4 that triggers an E_STRICT in PHP 5 should trigger an E_WARNING (or whatever) in PHP 6. This leaves E_STRICT available for use in PHP 6 to tag deprecated items from PHP 5 that will trigger E_WARNINGS in PHP 7. And on and on... --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On Sun, 4 Jun 2006, Andrei Zmievski wrote: > I am sorry if I missed the whole thread. I think that using the > result of __toString() for indexing objects is a bad idea. If we want > to allow this behavior (which is actually useful in some situations), > I'd rather we had a __hash() method or something similar to what > Python does. The string representation of the object and its hashed > representation may be very different. After sitting on the fence on this one for a few days, I agree with Andrei. For example, for an eBay Item object, my __toString() returns the Title, but that's not unique, so my __toHash() returns the numeric ID, which is. Furthermore, if my __toString() was unique, and I was relying on that for keys in an array, I would have to mark that method as final; otherwise, someone might unknowingly destroy the uniqueness in a child class and break my code. That's not ideal because there could otherwise be many good reasons that someone would want to override __toString(). In contrast, it's unlikely that you would override __toHash(), and it's pretty obvious that you shouldn't do something that could cause collisions. The other proposal, where PHP generates a unique object id, would also be fine. Even better, perhaps. I'm not sure what I think yet. -adam -- [EMAIL PROTECTED] | http://www.trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On 6/5/06, Adam Maccabee Trachtenberg <[EMAIL PROTECTED]> wrote: For example, for an eBay Item object, my __toString() returns the Title, but that's not unique, so my __toHash() returns the numeric ID, which is. While I wouldn't be surprised if you completely ignore my opinion, however I think the __toHash implementation should happen in an interface, rather than happening automagically. That will make it just a little bit more predicatable. Michael
Re: [PHP-DEV] Missing __toString() part
On Jun 4, 2006, at 8:33 PM, Michael Gall wrote: For example, for an eBay Item object, my __toString() returns the Title, but that's not unique, so my __toHash() returns the numeric ID, which is. While I wouldn't be surprised if you completely ignore my opinion, however I think the __toHash implementation should happen in an interface, rather than happening automagically. That will make it just a little bit more predicatable. +1 on that from me. There is definitely a use for a __toHash() magic function WITHOUT it being automagical. An automagical one would probably lead to a lot of confusion and odd behaviors. Let people use the feature if they need it and ignore it otherwise. However, if it was automagical, I'd agree with previous comments: Make it a string based on the hash table pointer. Gwynne SkyTag Software -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Need to think about that but I remembered after I sent my email that
I was wrong about something like "num:num" (e.g. "3:4") requiring to
start with a letter in order not to be auto-converted to a numbered
index. The reason for the confusion is the behavior of strtol() in:
print "3:4" + 1;
Which will convert "3:4" to "3".
Anyway, will think a bit more about your email and hopefully have
some more ideas by tomorrow.
Thx.
Andi
At 09:17 AM 6/4/2006, Rasmus Lerdorf wrote:
Andi Gutmans wrote:
Again, I don't think we should have a hash but a unique id which
can be used as an array key and in other things. Difference. Hash
implies that it's not unique, I'm talking about unique. So yes, I'd
take the starting point of Marcus' proposal but:
a) Make the value start with a letter so that this isn't
autoconverted but taken as a literal string key. Again, something
like "id=%p:%d"
b) Not call it hash because I see this as a unique id and not as a
hash value which is not unique necessarily.
c) This should be something outside SPL and part of the engine.
Question is again, whether it's explicit or implicit (back to the
question I had earlier). Do you just want to add a function which
returns this thing or do you want $arr[$obj] to automatically ask for it.
These are valid questions and should be answered.
I think if we implement a way to get a hash from an object, or at
least a unique identifier that can be used as a hash, then it should
be implicit just like other things are implicitly converted when the
context is clear. Of course, you should also be able to force it
explicitly. And I don't think there is any point in doing this
unless we also implicitly go the other way. From unique identifier
to object. As in:
class foo { function bar($arg) { echo $arg; } }
$obj1 = new foo;
$obj2 = new foo;
$a = array($obj1=>1,$obj2=>2);
foreach($a as $k=>$v) {
$k->bar($v);
}
Unless this works, I am not sure there is any point to all this. To
me the end goal is to make it possible to use types other than
strings and numbers as array indices which to me also means we
should look at doing the same for arrays.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On Sun, 2006-06-04 at 20:49, Gwynne wrote: > On Jun 4, 2006, at 8:33 PM, Michael Gall wrote: > >> For example, for an eBay Item object, my __toString() returns the > >> Title, but that's not unique, so my __toHash() returns the numeric > >> ID, > >> which is. > > While I wouldn't be surprised if you completely ignore my opinion, > > however I > > think the __toHash implementation should happen in an interface, > > rather than > > happening automagically. That will make it just a little bit more > > predicatable. > > +1 on that from me. There is definitely a use for a __toHash() magic > function WITHOUT it being automagical. An automagical one would > probably lead to a lot of confusion and odd behaviors. Let people use > the feature if they need it and ignore it otherwise. But enforcing it's use via an interface means class users that don't want to use interfaces now need to use interfaces. Also the other magical functions aren't linked to interfaces, why change tradition? Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
On Sat, June 3, 2006 6:42 am, Marcus Boerger wrote: > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. I use objects rarely, and am not sure I care all that much, but... Seems to me that there is a REALLY good chance that there ARE scripts "out there" that rely on current behaviour of: $a = new Foo(); $arr[$a] = 42; Never mind that that's a really dumb thing to have -- Somebody is relying on it doing whatever it does... Whether that is erroring out or just turning all objects into "" doesn't matter. Somebody relies on it doing the same thing it always did. Don't break that, please, in 5.2 -- Do whatever you want in 6.0 on that. This all seems like much ado about nothing to me. Anybody brainy enough to NEED their objects as array indices can probably manage to write a function to uniquely identify their/all objects. Sorry if my votes aren't fitting into the schema of voting... I kinda got glassy-eyed with this whole thread, to tell the truth. -- Like Music? http://l-i-e.com/artists.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
As far as I can see, and I'm sure someone will be kind enough to correct me if I'm wrong, but there is no current behaviour for it, it returns a warning. $a = new stdClass; $b[$a] = 0; Warning: Illegal offset type in t3.php on line 2 And results in an empty array (in this case) so it does nothing. -bok On 6/5/06, Richard Lynch <[EMAIL PROTECTED]> wrote: On Sat, June 3, 2006 6:42 am, Marcus Boerger wrote: > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. I use objects rarely, and am not sure I care all that much, but... Seems to me that there is a REALLY good chance that there ARE scripts "out there" that rely on current behaviour of: $a = new Foo(); $arr[$a] = 42; Never mind that that's a really dumb thing to have -- Somebody is relying on it doing whatever it does... Whether that is erroring out or just turning all objects into "" doesn't matter. Somebody relies on it doing the same thing it always did. Don't break that, please, in 5.2 -- Do whatever you want in 6.0 on that. This all seems like much ado about nothing to me. Anybody brainy enough to NEED their objects as array indices can probably manage to write a function to uniquely identify their/all objects. Sorry if my votes aren't fitting into the schema of voting... I kinda got glassy-eyed with this whole thread, to tell the truth. -- Like Music? http://l-i-e.com/artists.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xnyo - http://xnyo.odynia.org/
[PHP-DEV] need the spam moderated in pecl-dev
it looks likes there's too many spam in pecl-dev these days. is that list moderated yet? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Marcus Boerger wrote: > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. +1 -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Missing __toString() part
Rasmus Lerdorf wrote: > I think if we are going to add a toHash thing, it should trigger when > the object is used in a hash context, just like toString triggers when > it is used in a string context. This makes sense to me, too. -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI
This patch fixes very specific bug. "php -v" calls RINIT() functions, php with php-gtk throws error from RINIT if we run php from telent/ssh session, because it cannot open DISPLAY. As result we don't go into request shutdown (shutdown_memory_manager() is called there) sequence and doing module shutdown and tsrm_shutdown(). Because request_shutdown() wasn't done we didn't cleared emalloced memory, and trying to do it during tsrm_shutdown() but some globals (sapi globals) are destroyed in this time. As result we get a crash. Thanks. Dmitry. > -Original Message- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Friday, June 02, 2006 10:08 PM > To: Dmitry Stogov; 'Steph Fox'; 'Frank M. Kromann' > Cc: 'internals'; 'Antony Dovgal'; 'Xuefer' > Subject: RE: [PHP-DEV] tsrm_shutdown() and the CLI SAPI > > > I don't understand this patch. Doesn't this completely remove > printing memory leaks? We never fixed this bug but as it was only > relevant to the debug version and dl() we were OK with it... Of > course there's also the option of not calling DL_UNLOAD(). > > Andi > > At 04:05 AM 6/1/2006, Dmitry Stogov wrote: > >Hi Stepth, > > > >I reproduced crash of php-gtk on linix with php-zts. > >I mean running "php -v" then php.ini contains > "extension=gtk2.so". The > >crash occurs only then php compiled with --enable-debug. > > > >The reason of the crash is a bug in ZE that is activated by memory > >leaks in php-gtk. In case of "php -v" we don't do request > >startup/shutdown and as result we don't handle memory leaks > on request > >shutdown. During tsrm_shutdown() shutdow_nmemory_manager() is called > >after > >sapi_shutdown() and as result we cannot access sapi_globals > then trying > >to print information about memory leaks and crashes. > > > >The solution - don't print information about memory leaks during > >tsrm_shutdown(). > > > >Patch for PHP_5_2 is attached, but it can be manually applied to any > >version. > > > >Steph, does you crash(es) go away with this patch? > > > >I am going to commit patch in 24h. > >Any objections? > > > >Thanks. Dmitry. > > > > > -Original Message- > > > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, June 01, 2006 10:29 AM > > > To: Steph Fox; Frank M. Kromann > > > Cc: 'internals'; 'Antony Dovgal'; Dmitry Stogov; 'Xuefer' > > > Subject: Re: [PHP-DEV] tsrm_shutdown() and the CLI SAPI > > > > > > > > > As we are not planning to release a new version within the next > > > couple of weeks, I suggest before jumping to conclusions > we take a > > > look at it. > > > > > > If you really need to comment out that line in the > meanwhile that's > > > OK with me. > > > > > > Andi > > > > > > At 09:50 PM 5/31/2006, Steph Fox wrote: > > > >>>Yes, it would, given the root cause - but would you > really want > > > >>>to break the whole of PHP for an academic exercise? > > > >> > > > >>It's not really an academic exercise. If we know there's a bug > > > >>someplace we should at least look into it and try and > understand > > > >>it. > > > > > > > >Frank's referring to Zeev's three-years-ago decision to > simply opt > > > >out of tsrm_shutdown() here... he's suggesting we revert it. > > > > > > > >>Then if we decide to remove the trsm_shutdown call for a good > > > >>reason (circular dependency, blah blah blah) then we > can do that > > > >>and put a nice fat comment on why it's the right thing > to do. But > > > >>I do think it's benefical to try and understand what's > happening. > > > > > > > >Fine, but breaking working code while you're trying to > understand > > > >what's happening is far from beneficial to our users. Can't > > > we at least #0 it? > > > > > > > >> > > > >>Andi > > > > > > -- > > > 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
RE: [PHP-DEV] Missing __toString() part
We probably should support this, but not only for __toString(). Objects may also have internal get() (not __get()) and cast() handlers that should be supported too. Also usage of cast() in context of array offset don't say what do we like "int" or "string". Thanks. Dmitry. > -Original Message- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 03, 2006 3:42 PM > To: internals@lists.php.net > Cc: Dmitry Stogov; Andi Gutmans; Zeev Suraski; Ilia Alshanetsky > Subject: [PHP-DEV] Missing __toString() part > > > Hello guys, > > the attached patch closes one more __toString() part. It > allows to use objects that define __toString as indexes to > arrays. What do you guys think about this, should we add it > or stay with the old behavior that didn't allow objects as > indexes at all. > > -- > Best regards, > Marcus mailto:[EMAIL PROTECTED] > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
