One additional comment, I am not sure about the manual merge of
properties. Maybe it should create an additional property called
"debugInfo" or something similar and store the result of __debugInfo
in it? It could be more user-friendly and less confusing.

Functionally speaking, the merge has to happen regardless since we
can't just put temporary elements into the properties table and return
that. Sure we could do the work for the user by putting the merge in
the standard object handler, but what does it buy us?

From my point of view, it buys us less options for the user. By
returning the result of __debugInfo() as-is, the class author can
replace, merge, or stuff debug into an extra prop at their discretion.
By making a unilateral decision to merge, we exclude the option of
not including certain props. By making the decision to put
__debugInfo() result into a specific '__debug' prop, we take all the
options away.

Personally, I'm for giving power to the user here. (Not least because
my use-case would quite like being able to control what's shown for
var_dump())

-Sara

Hi all,

Sorry for off topic.

Love it, two things: the var_dump() properties will be replaced (not
merged) with the "real" properties in the object (I am asking as that would
make it very very cool for stuff like doctrine, where lazy loaded entities
are way too large to dump)? As for the name, I would prefer __debugInfo()
as in __callStatic(). I know there is __set_state() but that's something
that needs deprecation and fixing :)

Could anyone add __setState() for 5.6?

Why would you want to do that? If at all, all the newer methods should
be __debug_info etc. __set_state was first and changing it to
__setState() would mean that var_export'ed() variables in < PHP 5.6
would now no longer work? Or the other way around? It's a cosmetic
change that helps nobody—just like renaming other standard functions to
make them more "organised".

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Hello!

I would like to notice, that there is method __set_state() that can be used
to set internal state of object. We can introduce __get_state() method that
will be invoked in var_dump(), etc... Personally I don't like __lower_caps
name of this method, but it will be consistent with __set_state() :)

2014/1/22 Ivan Enderlin @ Hoa ivan.enderlin@hoa-project.net

Hello :-),

Hi all !

Le 21 janv. 2014 à 22:26, Sara Golemon pollita@php.net a écrit :

Something new to argue about:

https://wiki.php.net/rfc/debug-info

Very interesting feature (i have personally thinking about that several
time in the past).
However, i think that __dump() is a better name from the end user point
of view.
__debug_info() is a good name from the point of view of a C developer
which works on the Zend Engine or on C extensions, but from the end user
point of view, it’s not the case.
And this new magical method is used internally by var_dump() so __dump()
seems to me a better name.
Maybe __set_dump() is an alternative too, because __set_state() is used
internally by var_export(), but i’m not sure that it’s a better name than
__dump which is very explicit and intuitive.

+1 for __debug which is simpler than __debugInfo. The -info suffix
does not add any relevant meaning about the method behavior.

Moreover, is this method able to throw an exception?

Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

+1 for __debug which is simpler than __debugInfo. The -info suffix
does not add any relevant meaning about the method behavior.

I feel the same here. PHP already has plenty of names which are longer
than they ought to be, or redundant, let's not add another. :)

--
Andrea Faulds
http://ajf.me/

On Tue, Jan 21, 2014 at 1:56 PM, Johannes Schlüter
johannes@schlueters.de wrote:

What impact does this have to debuggers like Xdebug?

I'd want Derick to weigh in on that. I'm not sure if XDebug only
looks at the get_properties hook, or considers the get_debug_info hook
as well.

Not yet, but I was hacking on a branch that uses that hook too, as it's
pretty handy to expose through the debugger. I'd probably namespace it
though so it doesn't conflict with "real" properties.

cheers,
Derick

Hi,

why not use __toString?

class File {
// "Resource(stream)" isn't all that useful
private $fp;

 // But all the stream meta data is
 public function __toString() {
     return $this->fp ? print_r(stream_get_meta_data($this->fp), 

true) : ''; // var export, what ever you like
}

 public function open($filename, $mode = 'r'){
     $this->fp = fopen($filename, $mode);
 }

}

$f = new File;
echo $f; // object(File)#1 { }
$f->open('http://php.net');
echo $f;

cryptocompress

Because the __toString allows a class to decide how to react when
treated like a string. Sure, that could be debug info, but it could be
printing a full-blow decorator implementation (e.g. Zend\Form\Form), a
number, class name, etc. What Sara is proposing is specific to object
debugging.