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
