[PHP-DEV] [RFC] Class instances counter
https://wiki.php.net/rfc/instance_counter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Class instances counter
I see little value in having a function that tells me how many objects of any kind I have instantiated. Mostly, I see it as a way to help teach people about assignment of objects works in PHP: $a = new MyClass(); $b = $a; var_dump(get_object_count()); And that's about the sum of how useful I think this is. If it were to be able to narrow it to a specific class then it *might* be a little more useful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Class instances counter
I'm with Morrison, I see no actual use for this. It's cool, but what would you use it for? On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison morrison.l...@gmail.com wrote: I see little value in having a function that tells me how many objects of any kind I have instantiated. Mostly, I see it as a way to help teach people about assignment of objects works in PHP: $a = new MyClass(); $b = $a; var_dump(get_object_count()); And that's about the sum of how useful I think this is. If it were to be able to narrow it to a specific class then it *might* be a little more useful. -- 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] Class instances counter
On Mon, Apr 8, 2013 at 4:07 PM, Madara Uchiha dor.tchi...@gmail.com wrote:
I'm with Morrison, I see no actual use for this.
It's cool, but what would you use it for?
On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison morrison.l...@gmail.com
wrote:
I see little value in having a function that tells me how many objects
of any kind I have instantiated. Mostly, I see it as a way to help
teach people about assignment of objects works in PHP:
$a = new MyClass();
$b = $a;
var_dump(get_object_count());
And that's about the sum of how useful I think this is.
If it were to be able to narrow it to a specific class then it *might*
be a little more useful.
It would be useful if you had functions in PHP that could tell you where
instances are stored in the current scope. Extensions like Reflection are
currently used in a wide variety of ways to produce autonomous factory
builders that can workout the relationships between different classes and
virtually induce dependency injection. But PHP currently has no way to
figure out where instances are sitting around in memory since the engine
abstracts this nuisance of memory management away from user space (and for
good reason).
As an example if you had the following code, it would not be obvious why
the object is not destroyed at the point unset($object) is called if you
were new to PHP.
$object = new stdClass;
$foo = $object;
unset($object);
A lot of people depend on destructors to solve cleanup problems in complex
PHP code bases. Though PHP won't invoke a destructor until the last
instance to an object has been destroyed, but it's not always obvious where
an instance sits unless you work this out ahead of time in your code.
/* For example building on the previous code... */
$object = new stdClass;
$foo = $object;
/* If you knew what variables carry the instance you could easily see it's
the same instance */
var_dump($object, $foo);
object(stdClass)#1 (0) {
}
object(stdClass)#1 (0) {
}
But there's no easy way to work out these relationships in user space
without writing a lot of boilerplate code. You would have to hack a
combination of get_defined_vars() and var_dump() with output buffering to
basically manually parse out class names and instance numbers then work out
the relationships yourself. That would be pretty slow in user space and
cumbersome.
/* If we had a function that could give you the variable to class/instance
relationship directly in each scope that could be quite useful */
var_dump(get_class_instances());
array(2) {
[object]=
array(2) {
[class]=
string(8) stdClass
[instance]=
int(1)
}
[foo]=
array(2) {
[class]=
string(8) stdClass
[instance]=
int(1)
}
}
So assuming the above example is an array of variable/class relationships
we could more easily workout that $foo and $object are pointing to the same
instance. I don't think it's such a strongly needed feature though. I just
think this in combination with the same problem we have with references
(you can't find references autonomously either) would be neat. That's all.
/my two cents
--
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
[PHP-DEV] trigger_error() enhancements
I was thinking it'd be useful if people could switch between throwing exceptions and displaying errors. If throw were a function and not a language construct one could do $function($error) where $function was a string equal to either 'trigger_error' or 'throw'. But alas that's not possible. In lieu of that it seems like it'd be useful if maybe a new error type constant could be added - E_USER_THROWABLE - that'd turn trigger_error into a throw. You wouldn't be able to use custom Exception classes in this instance but I think that'd be acceptable. ie. if you want more versatility use throw. If you just want to be able to switch between error's and thrown exceptions use trigger_error(). Also, I think it'd be useful if developers could specificy which line number and file name the error (or exception) displays For example... I was trying to implement support for stream_notification_callback in a custom stream wrapper. In my tests if you pass a non-callable string to the built-in ftp stream via, let's say, fopen(), you get an error saying failed to call user notifier on the fopen() line. But with custom stream wrappers the best you can do is to use trigger_error(). But that means that it's going to show not the line of the fopen() but instead the line of the trigger_error(). Which is of limited usefulness I'd say since the trigger_error() isn't where the error actually is. If a developer could control which line numbers and file names were displayed they could iterate through debug_backtrace() to get the actual line number they wanted to display. What are your thoughts?
Re: [PHP-DEV] trigger_error() enhancements
What's wrong with set_error_handler()? http://php.net/manual/en/function.set-error-handler.php (Aside for the fact that any uncaught warning would be fatal). On Mon, Apr 8, 2013 at 11:51 PM, Thomas Anderson zeln...@gmail.com wrote: I was thinking it'd be useful if people could switch between throwing exceptions and displaying errors. If throw were a function and not a language construct one could do $function($error) where $function was a string equal to either 'trigger_error' or 'throw'. But alas that's not possible. In lieu of that it seems like it'd be useful if maybe a new error type constant could be added - E_USER_THROWABLE - that'd turn trigger_error into a throw. You wouldn't be able to use custom Exception classes in this instance but I think that'd be acceptable. ie. if you want more versatility use throw. If you just want to be able to switch between error's and thrown exceptions use trigger_error(). Also, I think it'd be useful if developers could specificy which line number and file name the error (or exception) displays For example... I was trying to implement support for stream_notification_callback in a custom stream wrapper. In my tests if you pass a non-callable string to the built-in ftp stream via, let's say, fopen(), you get an error saying failed to call user notifier on the fopen() line. But with custom stream wrappers the best you can do is to use trigger_error(). But that means that it's going to show not the line of the fopen() but instead the line of the trigger_error(). Which is of limited usefulness I'd say since the trigger_error() isn't where the error actually is. If a developer could control which line numbers and file names were displayed they could iterate through debug_backtrace() to get the actual line number they wanted to display. What are your thoughts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trigger_error() enhancements
That only addresses my first idea, however, one problem with it I see is that there's not as much fine tuned granularity with it. What if, for error produced by some functions, you wanted to display an HTML page showing the error and other errors you just wanted to silently log it to the DB or something. With catching you can just catch each function's errors and handle them as you see fit on a one off basis without unilaterally effecting how all errors are handled. Also, I think catching makes for more linear easier to read code. Or at least it can. You want to know how the error is handled? Just scroll down a line or two to the catch block. With error handling you can't scroll down a line or two - you have to go to the top, to the bottom, to another file, or whatever. Certainly it's possible to write hard to read code with try / catch blocks too (like if you have the whole file in a giant try block) but with set_error_handler() it's not just possible - it's almost guaranteed. On Mon, Apr 8, 2013 at 4:51 PM, Madara Uchiha dor.tchi...@gmail.com wrote: What's wrong with set_error_handler()? http://php.net/manual/en/function.set-error-handler.php (Aside for the fact that any uncaught warning would be fatal). On Mon, Apr 8, 2013 at 11:51 PM, Thomas Anderson zeln...@gmail.com wrote: I was thinking it'd be useful if people could switch between throwing exceptions and displaying errors. If throw were a function and not a language construct one could do $function($error) where $function was a string equal to either 'trigger_error' or 'throw'. But alas that's not possible. In lieu of that it seems like it'd be useful if maybe a new error type constant could be added - E_USER_THROWABLE - that'd turn trigger_error into a throw. You wouldn't be able to use custom Exception classes in this instance but I think that'd be acceptable. ie. if you want more versatility use throw. If you just want to be able to switch between error's and thrown exceptions use trigger_error(). Also, I think it'd be useful if developers could specificy which line number and file name the error (or exception) displays For example... I was trying to implement support for stream_notification_callback in a custom stream wrapper. In my tests if you pass a non-callable string to the built-in ftp stream via, let's say, fopen(), you get an error saying failed to call user notifier on the fopen() line. But with custom stream wrappers the best you can do is to use trigger_error(). But that means that it's going to show not the line of the fopen() but instead the line of the trigger_error(). Which is of limited usefulness I'd say since the trigger_error() isn't where the error actually is. If a developer could control which line numbers and file names were displayed they could iterate through debug_backtrace() to get the actual line number they wanted to display. What are your thoughts?
Re: [PHP-DEV] [RFC] Class instances counter
On 04/08/2013 09:07 PM, Madara Uchiha wrote: I'm with Morrison, I see no actual use for this. It's cool, but what would you use it for? On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison morrison.l...@gmail.com wrote: I see little value in having a function that tells me how many objects of any kind I have instantiated. Mostly, I see it as a way to help teach people about assignment of objects works in PHP: $a = new MyClass(); $b = $a; var_dump(get_object_count()); And that's about the sum of how useful I think this is. If it were to be able to narrow it to a specific class then it *might* be a little more useful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I see some merit in the idea that during development of an application it could be useful to get a profile view of the object store, without affecting those objects or introducing new objects in order to provide that view. There are other run-time use cases, but for me, mostly development and debugging, without being intrusive or having any real impact on the application or object store. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Class instances counter
On 09/04/13 10:29, Joe Watkins wrote: On 04/08/2013 09:07 PM, Madara Uchiha wrote: I'm with Morrison, I see no actual use for this. It's cool, but what would you use it for? On Mon, Apr 8, 2013 at 10:47 PM, Levi Morrison morrison.l...@gmail.com wrote: I see little value in having a function that tells me how many objects of any kind I have instantiated. Mostly, I see it as a way to help teach people about assignment of objects works in PHP: $a = new MyClass(); $b = $a; var_dump(get_object_count()); And that's about the sum of how useful I think this is. If it were to be able to narrow it to a specific class then it *might* be a little more useful. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I see some merit in the idea that during development of an application it could be useful to get a profile view of the object store, without affecting those objects or introducing new objects in order to provide that view. There are other run-time use cases, but for me, mostly development and debugging, without being intrusive or having any real impact on the application or object store. Isn't that what a debugger is for? Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
Hey: bug is described at #64554 I proposal to add a leading backslash to all classnames (not only ns names, since no harm, consistent and make sense) when doing serialize, var_export etc. what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/
Re: [PHP-DEV] [PROPOSAL] add a leading backslash to classname when serializing/var_exporting
Sounds good. With PHP moving in closer and closer with namespaces, this proposal will save some confusion in the more complex application debugging. I support. +1 On Apr 9, 2013 6:29 AM, Laruence larue...@php.net wrote: Hey: bug is described at #64554 I proposal to add a leading backslash to all classnames (not only ns names, since no harm, consistent and make sense) when doing serialize, var_export etc. what do you think? thanks -- Laruence Xinchen Hui http://www.laruence.com/
