Object of class Person could not be converted to string

[phpCodeHead]

Code which should allow my constructor to accept arguments:

<?php
class Person {
function __construct($na me)
{
$this->name = $name;
}

function getName()
{
return $this->name;
}

function printName()
{
print $this->name;
}

private $name;
}

$judy = new Person("Judy") . "\n"; // <- this is line parser don't
like
$joe = new Person("Joe") . "\n";

$judy->printName() . '<br />';
$joe->printName() . '<br />';
?>

Outputs:

Catchable fatal error: Object of class Person could not be converted
to string

Anyone seen this before? Know why? Am I missing something here?

Thanks all...

Gene Kelley
LAMP Web Developer
bizFlowDesigns. com

[Schraalhans Keukenmeester]

Re: Object of class Person could not be converted to string

At Mon, 11 Jun 2007 04:46:57 +0000, phpCodeHead let h(is|er) monkeys type:

Code which should allow my constructor to accept arguments:
>
<?php
class Person {
function __construct($na me)
{
$this->name = $name;
}
>
function getName()
{
return $this->name;
}
>
function printName()
{
print $this->name;
}
>
private $name;
}
>
$judy = new Person("Judy") . "\n"; // <- this is line parser don't
like
$joe = new Person("Joe") . "\n";
>
$judy->printName() . '<br />';
$joe->printName() . '<br />';
?>
>
Outputs:
>
Catchable fatal error: Object of class Person could not be converted
to string
>
Anyone seen this before? Know why? Am I missing something here?
>
Thanks all...
>
Gene Kelley

What are you trying to achieve by concatenating "\n" to an object?
Your constructor creates an instance of your class, not a string.
Since you then concatenate it with ."\n" PHP attempts to convert the
object to a string, and fails. If you want that, you have to create your
own stringifier inside the class definition.

If you want to have the string "Judy\n" in your object, pass it as a
single string : $judy = new Person ("Judy\n");



--
Schraalhans Keukenmeester - schraalhans@the .Spamtrapexampl e.nl
[Remove the lowercase part of Spamtrap to send me a message]

"strcmp('apples ','oranges') < 0"

[gosha bine]

Re: Object of class Person could not be converted to string

On 11.06.2007 06:46 phpCodeHead wrote:

Code which should allow my constructor to accept arguments:
>
<?php
class Person {
function __construct($na me)
{
$this->name = $name;
}
>
function getName()
{
return $this->name;
}
>
function printName()
{
print $this->name;
}
>
private $name;
}
>
$judy = new Person("Judy") . "\n"; // <- this is line parser don't
like
$joe = new Person("Joe") . "\n";
>
$judy->printName() . '<br />';
$joe->printName() . '<br />';
?>
>
Outputs:
>
Catchable fatal error: Object of class Person could not be converted
to string
>
Anyone seen this before? Know why? Am I missing something here?
>
Thanks all...
>
Gene Kelley
LAMP Web Developer
bizFlowDesigns. com
>

This is a new "feature" of 5.2 - for some mystical reason they've
removed implicit object-to-string conversion. You must provide explicit
__toString if you're printing or concatenating your objects.


--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok

[Schraalhans Keukenmeester]

Re: Object of class Person could not be converted to string

At Mon, 11 Jun 2007 14:46:45 +0200, gosha bine let h(is|er) monkeys type:

On 11.06.2007 06:46 phpCodeHead wrote:

>Code which should allow my constructor to accept arguments:
>>
><?php
> class Person {
> function __construct($na me)
> {
> $this->name = $name;
> }
>>
> function getName()
> {
> return $this->name;
> }
>>
> function printName()
> {
> print $this->name;
> }
>>
> private $name;
> }
>>
> $judy = new Person("Judy") . "\n"; // <- this is line parser don't
>like
> $joe = new Person("Joe") . "\n";
>>
> $judy->printName() . '<br />';
> $joe->printName() . '<br />';
>?>
>>
>Outputs:
>>
>Catchable fatal error: Object of class Person could not be converted
>to string
>>
>Anyone seen this before? Know why? Am I missing something here?
>>
>Thanks all...
>>
>Gene Kelley
>LAMP Web Developer
>bizFlowDesigns .com
>>

>
This is a new "feature" of 5.2 - for some mystical reason they've
removed implicit object-to-string conversion. You must provide explicit
__toString if you're printing or concatenating your objects.

What should the contents of $judy be after assigning

$judy = new Person('Judy'). '\n';

be in your opinion?
'Judy\n' ?
'Object\n' ?
'sprinkled icecream\n' ?
'3.14159265\n' ?

Imho implicit obj2str conversion is meaningless, and though I have abused
the construct myself a few times I am glad they corrected this behaviour.
Having to define your own stringifier forces you to think about and
implement what is logically the proper meaning of a conversion to an
otherwise incompatible type.

I am not sure how many scripts out in the field rely on such implicit
conversion but I do sympathize with you; it's frustrating at times to find
yet another changed property between point releases. But don't you agree
it's still better to have to change some code to something more correct
than to have to deal with all kinds of odd behaviour?

Sh.



--
Schraalhans Keukenmeester - schraalhans@the .Spamtrapexampl e.nl
[Remove the lowercase part of Spamtrap to send me a message]

"strcmp('apples ','oranges') < 0"

[gosha bine]

Re: Object of class Person could not be converted to string

On 11.06.2007 20:58 Schraalhans Keukenmeester wrote:

>
Imho implicit obj2str conversion is meaningless, and though I have abused
the construct myself a few times I am glad they corrected this behaviour.
Having to define your own stringifier forces you to think about and
implement what is logically the proper meaning of a conversion to an
otherwise incompatible type.

That's exactly the point Zend developers are constantly missing. It is
not the responsibility of language designers to remove constructs that
may seem "useless" to them. An application programmer is the one who
decides which syntax is appropriate for her particular task. The job of
the language designer is to provide clean and consistent mechanism for
generating any possible expression, including "useless" ones. You don't
let a taxi driver decide where you're going to go, do you?

As to this specific case, removal of implicit toString is especially
stupid, because _every other_ type in php and _every other_ comparable
programming language supports it.



--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok

[Jerry Stuckle]

Re: Object of class Person could not be converted to string

gosha bine wrote:

On 11.06.2007 20:58 Schraalhans Keukenmeester wrote:

>>
>Imho implicit obj2str conversion is meaningless, and though I have abused
>the construct myself a few times I am glad they corrected this behaviour.
>Having to define your own stringifier forces you to think about and
>implement what is logically the proper meaning of a conversion to an
>otherwise incompatible type.

>
That's exactly the point Zend developers are constantly missing. It is
not the responsibility of language designers to remove constructs that
may seem "useless" to them. An application programmer is the one who
decides which syntax is appropriate for her particular task. The job of
the language designer is to provide clean and consistent mechanism for
generating any possible expression, including "useless" ones. You don't
let a taxi driver decide where you're going to go, do you?
>

No, but you let a taxi driver decide how you get there.

As to this specific case, removal of implicit toString is especially
stupid, because _every other_ type in php and _every other_ comparable
programming language supports it.
>

No, every other type in php doesn't support it. When was the last time
you tried to convert an object to an int, for instance?

And as for every other comparable programming language - no they don't.
But who cares? Other languages have features PHP doesn't have, and
PHP has features they don't have. It's comparing apples and oranges.

Personally, I've found the silent conversion allows for sloppy
programming and problems (like the one which started this thread). I'm
glad to see the implicit conversion is gone.

But if you really want it, the developers left a way for you to do so.
Good for them.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[gosha bine]

Re: Object of class Person could not be converted to string

On 12.06.2007 10:49 Jerry Stuckle wrote:

gosha bine wrote:

>On 11.06.2007 20:58 Schraalhans Keukenmeester wrote:

>>>
>>Imho implicit obj2str conversion is meaningless, and though I have
>>abused
>>the construct myself a few times I am glad they corrected this
>>behaviour.
>>Having to define your own stringifier forces you to think about and
>>implement what is logically the proper meaning of a conversion to an
>>otherwise incompatible type.

>>
>That's exactly the point Zend developers are constantly missing. It is
>not the responsibility of language designers to remove constructs that
>may seem "useless" to them. An application programmer is the one who
>decides which syntax is appropriate for her particular task. The job
>of the language designer is to provide clean and consistent mechanism
>for generating any possible expression, including "useless" ones. You
>don't let a taxi driver decide where you're going to go, do you?
>>

>
No, but you let a taxi driver decide how you get there.

You are not trying to refute a _metaphor_, are you? ;)

>

>As to this specific case, removal of implicit toString is especially
>stupid, because _every other_ type in php and _every other_ comparable
>programming language supports it.
>>

>
No, every other type in php doesn't support it. When was the last time
you tried to convert an object to an int, for instance?

I meant, every other php type supports implicit toString:

echo 123; - works
echo array(1, 2, 3); - works
echo fopen('blah', 'r'); - works

echo new Blah(); - DOES NOT work

>
And as for every other comparable programming language - no they don't.

Most languages support implicit toString for objects:

alert(new Blah()) - works in javascript
puts Blah.new - works in ruby
print Blah() - works in python
System.out.prin tln(new Blah()) - works in java

echo new Blah() - DOES NOT work in php

Are you saying other languages' designers care less about their
programmers? Why do they allow such a "useless" thing?

But who cares? Other languages have features PHP doesn't have, and PHP
has features they don't have. It's comparing apples and oranges.

Comparing programming languages and technologies is always productive,
there's always something to learn from each other.

>
Personally, I've found the silent conversion allows for sloppy
programming and problems (like the one which started this thread). I'm
glad to see the implicit conversion is gone.

What exactly are the problems which are solved by removing the silent
conversion?

>
But if you really want it, the developers left a way for you to do so.
Good for them.
>

An object without toString was converted to "object #x" or similar when
being printed. So was the behaviour prior to 5.2. Useless or not, it
simply worked. Now, it's broken and there's no way to make it work again.


--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok

[Schraalhans Keukenmeester]

Re: Object of class Person could not be converted to string

At Tue, 12 Jun 2007 10:22:23 +0200, gosha bine let h(is|er) monkeys type:

On 11.06.2007 20:58 Schraalhans Keukenmeester wrote:

>>
>Imho implicit obj2str conversion is meaningless, and though I have abused
>the construct myself a few times I am glad they corrected this behaviour.
>Having to define your own stringifier forces you to think about and
>implement what is logically the proper meaning of a conversion to an
>otherwise incompatible type.

>
That's exactly the point Zend developers are constantly missing. It is
not the responsibility of language designers to remove constructs that
may seem "useless" to them.

It's not about being useless, it's about being meaningless without a
specific definition of what conversion should be like. Any construction
conceivable, logically sound or not, will be deemed useful by at least
some people, at some point.

The default string conversion hitherto available in PHP comes across as a
stopgap solution offering programmers a coincidental and semantically
debatable shortcut. There are valid tools available allowing you to find
out about anything you want to know about an object or its class, there is
no need for the implicit tostring conversion.

An application programmer is the one who
decides which syntax is appropriate for her particular task. The job of
the language designer is to provide clean and consistent mechanism for
generating any possible expression, including "useless" ones. You don't
let a taxi driver decide where you're going to go, do you?

I don't tell a taxi driver how to get at the destination best, how to
drive, when to shift gear and what his car should look like. I use a cab
because it's -based on sound empirical evidence- a well-defined service
using the tools and tricks required for the trade. I can expect a car with
a driver who knows how to operate a vehicle, has a fair knowledge of how
to get somewhere fastest or most efficiently. If there's a change in how
taxis operate, I'd hope that change isn't based on customer whim.

As to this specific case, removal of implicit toString is especially
stupid, because _every other_ type in php and _every other_ comparable
programming language supports it.

PHP is as PHP does. There's plenty of constructs PHP has that other
languages miss, and each has its own merits. If all languages only mimic
others we'll end up with the first generation T-ford colour chart. You can
choose any colour, as long as it's black.

At time I'd wish I could use list constructs and logic Prolog style, yet
I'd frown if Zend PHP decided to conform PHP to Prolog's way of doing
things.

There are traits in C I don't particularly like, but few if any of them
fail to make sense in logical terms. And yes I am glad C's more or less
calmed down and set in stone by now (start the flames people ;-)), and PHP
will come to that level someday, or not. Right now it's a highly dynamical
and slightly volatile language, and each cycle the true shape of PHP
becomes clearer. Access baggage is cut off, faults corrected and omissions
plugged.

But that's all just my opinion of course.


--
Schraalhans Keukenmeester - schraalhans@the .Spamtrapexampl e.nl
[Remove the lowercase part of Spamtrap to send me a message]

"strcmp('apples ','oranges') < 0"

[Jerry Stuckle]

Re: Object of class Person could not be converted to string

gosha bine wrote:

On 12.06.2007 10:49 Jerry Stuckle wrote:

>gosha bine wrote:

>>On 11.06.2007 20:58 Schraalhans Keukenmeester wrote:
>>>>
>>>Imho implicit obj2str conversion is meaningless, and though I have
>>>abused
>>>the construct myself a few times I am glad they corrected this
>>>behaviour.
>>>Having to define your own stringifier forces you to think about and
>>>implement what is logically the proper meaning of a conversion to an
>>>otherwise incompatible type.
>>>
>>That's exactly the point Zend developers are constantly missing. It
>>is not the responsibility of language designers to remove constructs
>>that may seem "useless" to them. An application programmer is the one
>>who decides which syntax is appropriate for her particular task. The
>>job of the language designer is to provide clean and consistent
>>mechanism for generating any possible expression, including "useless"
>>ones. You don't let a taxi driver decide where you're going to go, do
>>you?
>>>

>>
>No, but you let a taxi driver decide how you get there.

>
You are not trying to refute a _metaphor_, are you? ;)
>

Sure! :-)

>>

>>As to this specific case, removal of implicit toString is especially
>>stupid, because _every other_ type in php and _every other_
>>comparable programming language supports it.
>>>

>>
>No, every other type in php doesn't support it. When was the last
>time you tried to convert an object to an int, for instance?

>
I meant, every other php type supports implicit toString:
>
echo 123; - works
echo array(1, 2, 3); - works
echo fopen('blah', 'r'); - works
>
echo new Blah(); - DOES NOT work
>

Sure, and every other type is built in.

>>
>And as for every other comparable programming language - no they don't.

>
Most languages support implicit toString for objects:
>
alert(new Blah()) - works in javascript
puts Blah.new - works in ruby
print Blah() - works in python
System.out.prin tln(new Blah()) - works in java
>
echo new Blah() - DOES NOT work in php
>

Well, for instance, C++ doesn't support it. And I've found Java's
default tostring() function to be particularly useless. That's why I
overload it in every class where I'm going to need it.

Are you saying other languages' designers care less about their
programmers? Why do they allow such a "useless" thing?
>

I'm not saying anything about any other languages' designers. All I'm
saying is I find it particularly useless.

> But who cares? Other languages have features PHP doesn't have, and
>PHP has features they don't have. It's comparing apples and oranges.

>
Comparing programming languages and technologies is always productive,
there's always something to learn from each other.
>

Sure. But different languages have different syntax and different
features. That's why they're different languages. No one language is
good for everything.

>>
>Personally, I've found the silent conversion allows for sloppy
>programming and problems (like the one which started this thread).
>I'm glad to see the implicit conversion is gone.

>
What exactly are the problems which are solved by removing the silent
conversion?
>

It makes you think about the implementation of the _tostring() method -
and specifically stops programming errors like which started this thread.

>>
>But if you really want it, the developers left a way for you to do so.
>Good for them.
>>

>
An object without toString was converted to "object #x" or similar when
being printed. So was the behaviour prior to 5.2. Useless or not, it
simply worked. Now, it's broken and there's no way to make it work again.
>
>

Yea, it was broken before. "object #x" is real descriptive, isn't it?
And of course, you still have var_dump() and print_r() to help you,
don't you?

I just see absolutely no problem with removing the default. I would
have more of a problem if they didn't allow the programmer a means to
implement it, however.

But heck - I seldom used it. Last time I can think of using it was for
other than debugging was in a simple Point class, where it would print
"(x,y)" or "(r, theta)", depending on whether I was using Cartesian or
Polar coordinates.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[gosha bine]

Re: Object of class Person could not be converted to string

On 12.06.2007 17:06 Jerry Stuckle wrote:

>I meant, every other php type supports implicit toString:
>>
>echo 123; - works
>echo array(1, 2, 3); - works
>echo fopen('blah', 'r'); - works
>>
>echo new Blah(); - DOES NOT work
>>

>
Sure, and every other type is built in.
>

Don't confuse 'type' and 'class'. 'Blah' is a class, 'object' is a
built-in type. 'echo some_resource' doesn't make more sense than 'echo
some_object', however it remains legal.

>>>
>>And as for every other comparable programming language - no they don't.

>>
>Most languages support implicit toString for objects:
>>
>alert(new Blah()) - works in javascript
>puts Blah.new - works in ruby
>print Blah() - works in python
>System.out.pri ntln(new Blah()) - works in java
>>
>echo new Blah() - DOES NOT work in php
>>

>
Well, for instance, C++ doesn't support it.

#include <iostream>

class A {};

int main() {
A* a = new A();
std::cout << a;
}

Works for me.

And I've found Java's
default tostring() function to be particularly useless. That's why I
overload it in every class where I'm going to need it.

Again, there's a difference between 'useless' and 'forbidden'. There are
many examples of completely useless code, do you think it all should be
forbidden at the language level?

>

>Are you saying other languages' designers care less about their
>programmers? Why do they allow such a "useless" thing?
>>

>
I'm not saying anything about any other languages' designers. All I'm
saying is I find it particularly useless.

And I wasn't talking about implicit toString being useful or not. I'm
just looking for the reason why it was taken out of the language.

>

>> But who cares? Other languages have features PHP doesn't have, and
>>PHP has features they don't have. It's comparing apples and oranges.

>>
>Comparing programming languages and technologies is always productive,
>there's always something to learn from each other.
>>

>
Sure. But different languages have different syntax and different
features. That's why they're different languages. No one language is
good for everything.

An interesting thought. Can I quote you on that? ;)

>

>>>
>>Personally, I've found the silent conversion allows for sloppy
>>programming and problems (like the one which started this thread).
>>I'm glad to see the implicit conversion is gone.

>>
>What exactly are the problems which are solved by removing the silent
>conversion?
>>

>
It makes you think about the implementation of the _tostring() method -
and specifically stops programming errors like which started this thread.
>

Thank you, I don't need a language feature that "makes me think". I
prefer to spend my time thinking about my problem domain, about my
algorithms and code structure and I'm not interested in "building
scaffolding to support the language itself" (c) Dave Thomas.

>>>
>>But if you really want it, the developers left a way for you to do
>>so. Good for them.
>>>

>>
>An object without toString was converted to "object #x" or similar
>when being printed. So was the behaviour prior to 5.2. Useless or not,
>it simply worked. Now, it's broken and there's no way to make it work
>again.
>>
>>

>
Yea, it was broken before. "object #x" is real descriptive, isn't it?

And why didn't they make it more descriptive and useful?

And of course, you still have var_dump() and print_r() to help you,
don't you?
>
I just see absolutely no problem with removing the default.

I wouldn't call it a problem. It's just a small design bug, that breaks
some (not much) old code and makes php a bit more unpredictable and
inconsistent than before.

I would
have more of a problem if they didn't allow the programmer a means to
implement it, however.
>
But heck - I seldom used it. Last time I can think of using it was for
other than debugging was in a simple Point class, where it would print
"(x,y)" or "(r, theta)", depending on whether I was using Cartesian or
Polar coordinates.
>

--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok

[Jerry Stuckle]

Re: Object of class Person could not be converted to string

gosha bine wrote:

On 12.06.2007 17:06 Jerry Stuckle wrote:
>

>>I meant, every other php type supports implicit toString:
>>>
>>echo 123; - works
>>echo array(1, 2, 3); - works
>>echo fopen('blah', 'r'); - works
>>>
>>echo new Blah(); - DOES NOT work
>>>

>>
>Sure, and every other type is built in.
>>

>
Don't confuse 'type' and 'class'. 'Blah' is a class, 'object' is a
built-in type. 'echo some_resource' doesn't make more sense than 'echo
some_object', however it remains legal.
>
>

Now you're playing with semantics. I'm not confusing them. The fact
remains - PHP knows how to convert built-in types. It does not know how
to convert user-defined objects.

And you're right - 'echo some_object' doesn't make sense - that's why
they took away the default conversion - it didn't make sense.

>>>>
>>>And as for every other comparable programming language - no they don't.
>>>
>>Most languages support implicit toString for objects:
>>>
>>alert(new Blah()) - works in javascript
>>puts Blah.new - works in ruby
>>print Blah() - works in python
>>System.out.pr intln(new Blah()) - works in java
>>>
>>echo new Blah() - DOES NOT work in php
>>>

>>
>Well, for instance, C++ doesn't support it.

>
#include <iostream>
>
class A {};
>
int main() {
A* a = new A();
std::cout << a;
}
>
Works for me.
>

Try putting some variables in your class and see what happens.

>

>And I've found Java's default tostring() function to be particularly
>useless. That's why I overload it in every class where I'm going to
>need it.

>
Again, there's a difference between 'useless' and 'forbidden'. There are
many examples of completely useless code, do you think it all should be
forbidden at the language level?
>

So, if it's useless, why not take it away? Why bother to maintain
something which has no use?

>>

>>Are you saying other languages' designers care less about their
>>programmers ? Why do they allow such a "useless" thing?
>>>

>>
>I'm not saying anything about any other languages' designers. All I'm
>saying is I find it particularly useless.

>
And I wasn't talking about implicit toString being useful or not. I'm
just looking for the reason why it was taken out of the language.
>

I suspect because it's useless. Shouldn't have been there in the first
place, and now they're correcting that.

>>

>>> But who cares? Other languages have features PHP doesn't have, and
>>>PHP has features they don't have. It's comparing apples and oranges.
>>>
>>Comparing programming languages and technologies is always
>>productive, there's always something to learn from each other.
>>>

>>
>Sure. But different languages have different syntax and different
>features. That's why they're different languages. No one language is
>good for everything.

>
An interesting thought. Can I quote you on that? ;)
>

>>

>>>>
>>>Personally , I've found the silent conversion allows for sloppy
>>>programmin g and problems (like the one which started this thread).
>>>I'm glad to see the implicit conversion is gone.
>>>
>>What exactly are the problems which are solved by removing the silent
>>conversion?
>>>

>>
>It makes you think about the implementation of the _tostring() method
>- and specifically stops programming errors like which started this
>thread.
>>

>
Thank you, I don't need a language feature that "makes me think". I
prefer to spend my time thinking about my problem domain, about my
algorithms and code structure and I'm not interested in "building
scaffolding to support the language itself" (c) Dave Thomas.
>

Tell me ONE LANGUAGE - including PHP - where you don't have to think to
use it.

>>>>
>>>But if you really want it, the developers left a way for you to do
>>>so. Good for them.
>>>>
>>>
>>An object without toString was converted to "object #x" or similar
>>when being printed. So was the behaviour prior to 5.2. Useless or
>>not, it simply worked. Now, it's broken and there's no way to make it
>>work again.
>>>
>>>

>>
>Yea, it was broken before. "object #x" is real descriptive, isn't it?

>
And why didn't they make it more descriptive and useful?
>

They did. They gave you the _tostring() function to do whatever you
want with it.

>

>And of course, you still have var_dump() and print_r() to help you,
>don't you?
>>
>I just see absolutely no problem with removing the default.

>
I wouldn't call it a problem. It's just a small design bug, that breaks
some (not much) old code and makes php a bit more unpredictable and
inconsistent than before.
>

Hasn't broken any of my code. But if you code sloppily, then yes, it
will break your code.

I would
>have more of a problem if they didn't allow the programmer a means to
>implement it, however.
>>
>But heck - I seldom used it. Last time I can think of using it was
>for other than debugging was in a simple Point class, where it would
>print "(x,y)" or "(r, theta)", depending on whether I was using
>Cartesian or Polar coordinates.
>>

>
>

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[gosha bine]

Re: Object of class Person could not be converted to string

On 12.06.2007 23:03 Jerry Stuckle wrote:

>>
>Again, there's a difference between 'useless' and 'forbidden'. There
>are many examples of completely useless code, do you think it all
>should be forbidden at the language level?
>>

>
So, if it's useless, why not take it away? Why bother to maintain
something which has no use?
>

Try to think logically about this (you did learn logic at your school,
right?)

You're trying to prove the following:

"implicit toString is useless and therefore should be removed from the
language" (C)

In order to prove the conclusion (C) you must prove two premises:

minor premise (p): "implicit toString is useless"
major premise (P): "everything that is useless should be removed from
the language"

You've put much effort in (p) and I think we can assume that you've
proved it. Now, please prove (P).


--
gosha bine

extended php parser ~ http://code.google.com/p/pihipi
blok ~ http://www.tagarga.com/blok

[Jerry Stuckle]

Re: Object of class Person could not be converted to string

gosha bine wrote:

On 12.06.2007 23:03 Jerry Stuckle wrote:
>

>>>
>>Again, there's a difference between 'useless' and 'forbidden'. There
>>are many examples of completely useless code, do you think it all
>>should be forbidden at the language level?
>>>

>>
>So, if it's useless, why not take it away? Why bother to maintain
>something which has no use?
>>

>
>
Try to think logically about this (you did learn logic at your school,
right?)
>
You're trying to prove the following:
>
"implicit toString is useless and therefore should be removed from the
language" (C)
>
In order to prove the conclusion (C) you must prove two premises:
>
minor premise (p): "implicit toString is useless"
major premise (P): "everything that is useless should be removed from
the language"
>
You've put much effort in (p) and I think we can assume that you've
proved it. Now, please prove (P).
>
>

No, I don't have to prove anything, Gosha. And I never claimed that
everything that is useless should be removed from the language. I only
claimed this "feechure" should be.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[james.gauth@googlemail.com]

Re: Object of class Person could not be converted to string

I agree with Gosha Bine, PHP prides itself with maintaining backward
compatibility (so much so that there's an unbelievable amount of cruft
in the language) yet they choose to break backward compatibility with
something like this? Why not allow a way to extend the base object
prototype to reproduce the old behaviour (or a more descriptive
behaviour)? Or why not, if a __toString() method isn't found, print
'Object' instead of throwing an exception?

Even the manual still states:
Objects are always converted to the string "Object". If you would like
to print out the member variable values of an object for debugging
reasons, read the paragraphs below. If you would like to find out the
class name of which an object is an instance of, use get_class(). As
of PHP 5, __toString() method is used if applicable.

No warning is given that if a __toString() method isn't defined it'll
throw an exception and handily fatal for you (since PHP 5.2). They
even state that a __toString() method is used 'if applicable'. I'm
guessing 'if applicable' in this case actually means 'without question
and will cause a fatal error in your scripts if you don't define it
when casting an object to a string'.

You *do* gain something from an implicit conversion to 'Object', you
gain the sure knowledge that string type-casting will work in *all*
cases regardless of variable type. You do not have to check what the
type of a variable is every time you would like to use it in a string
capacity. It's as if PHP is desperately trying to not be a loosely
typed language any more. The half-baked type-hinting feature is a
great example of this.

You lose far more from having your language behave inconsistently
between releases than you gain from forcing mandatory redundant coding
constructs. No mention is made in the change log with regards to what
is a reasonably intrinsic change to the language (type-casting should
be set in stone, or people should at least be made aware of it if it's
changed).

[Jerry Stuckle]

Re: Object of class Person could not be converted to string

james.gauth@goo glemail.com wrote:

I agree with Gosha Bine, PHP prides itself with maintaining backward
compatibility (so much so that there's an unbelievable amount of cruft
in the language) yet they choose to break backward compatibility with
something like this? Why not allow a way to extend the base object
prototype to reproduce the old behaviour (or a more descriptive
behaviour)? Or why not, if a __toString() method isn't found, print
'Object' instead of throwing an exception?
>

No, PHP has been lousy at maintaining backward compatibility.

Even the manual still states:
Objects are always converted to the string "Object". If you would like
to print out the member variable values of an object for debugging
reasons, read the paragraphs below. If you would like to find out the
class name of which an object is an instance of, use get_class(). As
of PHP 5, __toString() method is used if applicable.
>

Which version are you looking at? I don't see this in my 5.2.21
version. But it's not unusual for doc to lag the actual code changes, -
in PHP or any other product.

Irregardless, they do say they will use the __tostring() method, if
available.

Good programmers wouldn't leave something like this to the
compiler/interpreter; they'd define it themselves, anyway. Otherwise
you're just asking for bugs.

No warning is given that if a __toString() method isn't defined it'll
throw an exception and handily fatal for you (since PHP 5.2). They
even state that a __toString() method is used 'if applicable'. I'm
guessing 'if applicable' in this case actually means 'without question
and will cause a fatal error in your scripts if you don't define it
when casting an object to a string'.
>

Gee, just like any other missing method. Again - EXACTLY which version
of the doc are you using?

You *do* gain something from an implicit conversion to 'Object', you
gain the sure knowledge that string type-casting will work in *all*
cases regardless of variable type. You do not have to check what the
type of a variable is every time you would like to use it in a string
capacity. It's as if PHP is desperately trying to not be a loosely
typed language any more. The half-baked type-hinting feature is a
great example of this.
>

You gain a FALSE COMFORT that a string casting will work in some usable
manner.

You lose far more from having your language behave inconsistently
between releases than you gain from forcing mandatory redundant coding
constructs. No mention is made in the change log with regards to what
is a reasonably intrinsic change to the language (type-casting should
be set in stone, or people should at least be made aware of it if it's
changed).
>

You gain consistency - because now you are defining the __tostring()
method in a manner which makes sense to your program (and your class).
Not something PHP has to guess at.

In case you don't get it - I'm all for this change. I think one of
their more serious mistakes was to implement to implicit string
conversion for user-defined objects in the first place. It just
encourages more sloppy programming.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===