Everything

php

[patch] __string() method

php.internals

Jon Parise

22 years ago

Attached is a fairly simple (and rough) patch that adds support for a
"special" __string() object method to ZE2.  I wrote it for fun, but I
thought there might be general interest in the idea, so I'm posting it
here.  The idea is inspired by Python's __str__ method [1].

Here's how it works in practice:

class Foo { }

class Stringy extends Foo
{
function __string()
{
return 'blah';
}
}

$foo = new Foo();
$stringy = new Stringy();

print "$foo\n";
print "$stringy\n";


$a = (string)$foo;
$b = (string)$stringy;

print "$a\n";
print "$b\n";

Output:

Object id #1
blah
Object id #136238812
blah

So, essentially, if an object offers a __string() method, it will be
used whenever a string representation of the object is requested.  I
can see this being useful for things like object serialization or as a
shortcut for things like the Exception class's toString() method.

The patch is attached.  Comments are welcome.

[1] http://www.python.org/doc/current/ref/customization.html

--
Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)

(Marcus Börger)

22 years ago

Hello Jon,

Tuesday, September 2, 2003, 10:29:11 AM, you wrote:

JP> Attached is a fairly simple (and rough) patch that adds support for a
JP> "special" __string() object method to ZE2.  I wrote it for fun, but I
JP> thought there might be general interest in the idea, so I'm posting it
JP> here.  The idea is inspired by Python's __str__ method [1].


First why not name it toString() since for now we have consensus on sudlyCaps.
But i didn't bother with names yet when i made this patch:
http://marcus-boerger.de/php/ext/ze2/ze2-iterators-20030902.diff.txt

Second i think you should use the cast facility like i did in my patch.

Best regards,
Marcus                            mailto:helly@php.net

Jon Parise

22 years ago

On Tue, Sep 02, 2003 at 11:59:29AM +0200, Marcus Brger wrote:

> JP> Attached is a fairly simple (and rough) patch that adds support for a
> JP> "special" __string() object method to ZE2.  I wrote it for fun, but I
> JP> thought there might be general interest in the idea, so I'm posting it
> JP> here.  The idea is inspired by Python's __str__ method [1].
>
> First why not name it toString() since for now we have consensus on sudlyCaps.
> But i didn't bother with names yet when i made this patch:
> http://marcus-boerger.de/php/ext/ze2/ze2-iterators-20030902.diff.txt

I chose '__string' to follow the existing convention for "special"
method names (e.g. __construct, __clone, __call).  Also, I suspect
that many developers are already using toString() methods in their
classes, and I'm not sure we want to use them directly with having
them think about the semantics of their decision first.

> Second i think you should use the cast facility like i did in my patch.

I looked at the cast facility briefly and decided not to use it
because it meant including a new zend_std_* implementation for casting
(that function entry is currently NULL in zend_object_handers.c).

Admittedly, I wasn't comfortable at the time with writing a universal
casting handler, and because I only wanted to deal with string
conversions, I decided to just implement it as a separate dedicated
function entry.

--
Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)

Jon Parise

22 years ago

On Tue, Sep 02, 2003 at 11:45:29AM -0400, Jon Parise wrote:

> I chose '__string' to follow the existing convention for "special"
> method names (e.g. __construct, __clone, __call).  Also, I suspect
> that many developers are already using toString() methods in their
> classes, and I'm not sure we want to use them directly with having

^without

> them think about the semantics of their decision first.

--
Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)

(Marcus Börger)

22 years ago

Hello Jon,

Tuesday, September 2, 2003, 5:45:29 PM, you wrote:

> On Tue, Sep 02, 2003 at 11:59:29AM +0200, Marcus Brger wrote:

>> JP> Attached is a fairly simple (and rough) patch that adds support for a
>> JP> "special" __string() object method to ZE2.  I wrote it for fun, but I
>> JP> thought there might be general interest in the idea, so I'm posting it
>> JP> here.  The idea is inspired by Python's __str__ method [1].
>>
>> First why not name it toString() since for now we have consensus on sudlyCaps.
>> But i didn't bother with names yet when i made this patch:
>> http://marcus-boerger.de/php/ext/ze2/ze2-iterators-20030902.diff.txt

> I chose '__string' to follow the existing convention for "special"
> method names (e.g. __construct, __clone, __call).  Also, I suspect
> that many developers are already using toString() methods in their
> classes, and I'm not sure we want to use them directly with having
> them think about the semantics of their decision first.

All i care about at the moment are core extensions and the engine itself.
There all implemetnations of toString() are fine. So whatever the general
solution will be we need to apply to all conversions already written.

>> Second i think you should use the cast facility like i did in my patch.

> I looked at the cast facility briefly and decided not to use it
> because it meant including a new zend_std_* implementation for casting
> (that function entry is currently NULL in zend_object_handers.c).

> Admittedly, I wasn't comfortable at the time with writing a universal
> casting handler, and because I only wanted to deal with string
> conversions, I decided to just implement it as a separate dedicated
> function entry.

That's why i already said we should change the casting facility to be able
to handle only selected types and default for the rest.

--
Best regards,
Marcus                            mailto:helly@php.net

Moriyoshi Koizumi

22 years ago

Hi,

> > First why not name it toString() since for now we have consensus on sudlyCaps.
> > But i didn't bother with names yet when i made this patch:
> > http://marcus-boerger.de/php/ext/ze2/ze2-iterators-20030902.diff.txt
>
> I chose '__string' to follow the existing convention for "special"
> method names (e.g. __construct, __clone, __call).  Also, I suspect
> that many developers are already using toString() methods in their
> classes, and I'm not sure we want to use them directly with having
> them think about the semantics of their decision first.

__string() is fine with me, since in analogy to Java, toString() is prone
to have arbitrary meanings in comparison with a simple overloaded cast
operation.

> > Second i think you should use the cast facility like i did in my patch.
>
> I looked at the cast facility briefly and decided not to use it
> because it meant including a new zend_std_* implementation for casting
> (that function entry is currently NULL in zend_object_handers.c).

I need this functionality to implement i18n'ed string class, so
I'll reimplement your patch to use the default cast facility if necessary.

BTW, how about allowing zend_object_cast() to return a boolean value and
decide whether to use the default casting behaviour or the modified
one, Marcus? This seems to reduce such redundant effort.

Moriyoshi

(Marcus Börger)

22 years ago

Hello Moriyoshi,

Wednesday, September 3, 2003, 7:05:26 PM, you wrote:

> Hi,

>> > First why not name it toString() since for now we have consensus on sudlyCaps.
>> > But i didn't bother with names yet when i made this patch:
>> > http://marcus-boerger.de/php/ext/ze2/ze2-iterators-20030902.diff.txt
>>
>> I chose '__string' to follow the existing convention for "special"
>> method names (e.g. __construct, __clone, __call).  Also, I suspect
>> that many developers are already using toString() methods in their
>> classes, and I'm not sure we want to use them directly with having
>> them think about the semantics of their decision first.

> __string() is fine with me, since in analogy to Java, toString() is prone
> to have arbitrary meanings in comparison with a simple overloaded cast
> operation.

>> > Second i think you should use the cast facility like i did in my patch.
>>
>> I looked at the cast facility briefly and decided not to use it
>> because it meant including a new zend_std_* implementation for casting
>> (that function entry is currently NULL in zend_object_handers.c).

> I need this functionality to implement i18n'ed string class, so
> I'll reimplement your patch to use the default cast facility if necessary.

> BTW, how about allowing zend_object_cast() to return a boolean value and
> decide whether to use the default casting behaviour or the modified
> one, Marcus? This seems to reduce such redundant effort.

I did that in my patch so you can decide whether or not you want to support
the requested cast operation and fall back to the default if not (or call
the inherited one if any exists). But i'm still waiting for Zeev to comment
on that little change. Zeev ?

--
Best regards,
Marcus                            mailto:helly@php.net

Moriyoshi Koizumi

22 years ago

marcus.boerger@t-online.de (Marcus Börger) wrote:

> > BTW, how about allowing zend_object_cast() to return a boolean value and
> > decide whether to use the default casting behaviour or the modified
> > one, Marcus? This seems to reduce such redundant effort.
>
> I did that in my patch so you can decide whether or not you want to support
> the requested cast operation and fall back to the default if not (or call
> the inherited one if any exists). But i'm still waiting for Zeev to comment
> on that little change. Zeev ?

The patch is somewhat too big to demonstrate this, so it may be better to
separate it into several essential parts. Indeed I've overlooked it :)

Moriyoshi

(Marcus Börger)

22 years ago

Hello Moriyoshi,

Wednesday, September 3, 2003, 8:51:45 PM, you wrote:

> marcus.boerger@t-online.de (Marcus Börger) wrote:

>> > BTW, how about allowing zend_object_cast() to return a boolean value and
>> > decide whether to use the default casting behaviour or the modified
>> > one, Marcus? This seems to reduce such redundant effort.
>>
>> I did that in my patch so you can decide whether or not you want to support
>> the requested cast operation and fall back to the default if not (or call
>> the inherited one if any exists). But i'm still waiting for Zeev to comment
>> on that little change. Zeev ?

> The patch is somewhat too big to demonstrate this, so it may be better to
> separate it into several essential parts. Indeed I've overlooked it :)

Here's a strip down version which uses the function name "toString".
http://marcus-boerger.de/php/ext/ze2/ze2-tostring-20030902.diff.txt

As you can see it would now require every object implementing that function.
However the idea behind is that the cast handler should verify if a certain
interface was implemented and only then call that function which must then
be present. But the interface registering stuff is still missing (part of
the bigger patch - so i skipped that part for now).

The intersting point though is the cnage of the cast handler in c. It now
allows to support only selected conversions as already stated.

--
Best regards,
Marcus                            mailto:helly@php.net

Moriyoshi Koizumi

22 years ago

marcus.boerger@t-online.de (Marcus Börger) wrote:

> Here's a strip down version which uses the function name "toString".
> http://marcus-boerger.de/php/ext/ze2/ze2-tostring-20030902.diff.txt
>
> As you can see it would now require every object implementing that function.
> However the idea behind is that the cast handler should verify if a certain
> interface was implemented and only then call that function which must then
> be present. But the interface registering stuff is still missing (part of
> the bigger patch - so i skipped that part for now).

First, I think we'd better use 1(TRUE) / 0(FALSE) instead SUCCESS /
FAILURE for its return value because those two have different semantics.

And requiring a certain interface would be more accurate for canonical OO
programming, but I suppose it's not requisite for scripting languages.

> The intersting point though is the cnage of the cast handler in c. It now
> allows to support only selected conversions as already stated.

It's just one of my trivial ideas, that why don't us make it capable of
arbitrary casting operation rather than limiting it just for string casts?

Moriyoshi

l0t3k

22 years ago

> It's just one of my trivial ideas, that why don't us make it capable of
> arbitrary casting operation rather than limiting it just for string casts?

i agree here. this can be important for external integration e.g. Java and
COM

l0t3k

22 years ago

> It's just one of my trivial ideas, that why don't us make it capable of
> arbitrary casting operation rather than limiting it just for string casts?

i agree here. this can be important for external integration e.g. Java and
COM

(Marcus Börger)

22 years ago

Hello l0t3k,

Thursday, September 4, 2003, 2:56:16 PM, you wrote:

>> It's just one of my trivial ideas, that why don't us make it capable of
>> arbitrary casting operation rather than limiting it just for string casts?

> i agree here. this can be important for external integration e.g. Java and
> COM

A default __toString() doesn't hinder an extension that interoperates with
Java/COM or whatever external objects in anyway to handle their casting as
they like. In fact the interface approach would deliver the ability to hide
those internal differences so that the user can use the same interfaces for
all classes that provide such casting.

--
Best regards,
Marcus                            mailto:helly@php.net