|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2003-08-17 22:17 UTC] a at b dot c dot de
Description:
------------
String casting for objects. When used in a string context (a simple
example being "echo $object;") objects are currently cast to the string
"object", which is generally less than helpful.
The enhancement is to allow objects to have a method called, say,
"__string" or something similar that is called on an object whenever it
is used in a situation where a string is expected and returns a string
(or something, like a number, that can be readily cast to a string).
One could, for example, have a complex number class, with properties $r
and $i, with a method like
function __string()
{
$s = $this->r;
if($this->i>=0) $s.='+';
$s.=$this->i;
$s.='i';
return $s;
}
so that one can echo or concatenate complex numbers with impunity.
Many classes already possess "toString()" methods, no doubt in part to
Java's influence. These generally perform the role that I am advocating
for __string(), with the difference being that the latter is implicitly
called whenever necessary. Calling the new method "toString()" could be
hazardous for existing scripts that already use classes with methods
with this name. Backward compatibility can of course be achieved by
writing one of
function __string()
{ return $this->toString();
}
function toString()
{ return $this->__string();
}
which will give the two methods identical behaviour, except of course
for the fact that toString() is an ordinary method that needs to be
called explicitly.
Not to be confused with the operation of serialize(); __string() is
intended for e.g., human-readable string representations of an object
and isn't necessarily reversible to produce the original object. A
complex hierarchical object might, for example, generate XML as a
result of calling its __string() method; in the example above, a complex
number might have a string string representation of "-12+2.5i";
something containing binary data (e.g., an image) might return a textual
description of the data's contents rather than the data itself.
Needless to say, if the __string() method is absent, casting reverts to
the existing "cast to 'object'" behaviour.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Thu Jul 17 05:01:34 2025 UTC |
Is this still open? One method that (from this angle) appears quite elegant would be to give stdClass a __toString() method that simply returns "Object" (or even "Object" and an ID#, a la resources). Then any other __toString() methods in any other classes would simply be overriding this one. The clear advantage this gives is that __toString() can be then called with impunity on any object, safe in the knowledge that it exists. The type casting engine already knows how to cast objects to arrays; if it needs to cast the object to anything else it can hapily call __toString() and proceed from there. The obvious issue hinted at in the previous paragraph is that the entity that the object is cast to may require further casting in order to fit in with whatever expression is being evaluated at the time. This is something that may happen anyway: without rigorously type-checking (at runtime) the value returned by __toString() to ensure that it really is a string, it has to be assumed that the method could return anything, ranging from Void to Null to Object. And it's all too reasonable to expect that method writers will want to return, say, integers in the expectation that they will be cast to strings as per normal. So after an object has been cast into the result of its __toString() method, that result would need to be checked again, and, if necessary, recast again. And it's the method writer's own silly fault if PHP hangs when they write something that boils down to "function __toString(){return $this;}".