Object of class Person could not be converted to string

Code which should allow my constructor to accept arguments:

class Person {
function __construct($name)
{
$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() . '
';
$joe->printName() . '
';
?>

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

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:
>
> > class Person {
> function __construct($name)
> {
> $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() . '
';
> $joe->printName() . '
';
> ?>
>
> 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.Spamtrapexample.nl
[Remove the lowercase part of Spamtrap to send me a message]

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

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:
>
> > class Person {
> function __construct($name)
> {
> $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() . '
';
> $joe->printName() . '
';
> ?>
>
> 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

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:
>>
>> >> class Person {
>> function __construct($name)
>> {
>> $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() . '
';
>> $joe->printName() . '
';
>> ?>
>>
>> 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.Spamtrapexample.nl
[Remove the lowercase part of Spamtrap to send me a message]

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

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

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@attglobal.net
==================

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.println(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

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.Spamtrapexample.nl
[Remove the lowercase part of Spamtrap to send me a message]

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

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.println(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@attglobal.net
==================

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.println(new Blah()) - works in java
>>
>> echo new Blah() - DOES NOT work in php
>>
>
> Well, for instance, C++ doesn't support it.

#include

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

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.println(new Blah()) - works in java
>>>
>>> echo new Blah() - DOES NOT work in php
>>>
>>
>> Well, for instance, C++ doesn't support it.
>
> #include
>
> 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
>>>> 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.
>

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@attglobal.net
==================

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

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@attglobal.net
==================

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).

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

james.gauth@googlemail.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@attglobal.net
==================

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

On 22 Jun, 02:15, Jerry Stuckle wrote:
> james.ga...@googlemail.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.

Well, since you're using such a convincing argument here, I'll just go
ahead and refute your statement shall I? Here's the entire list of
backward incompatible changes made from a MAJOR revision in PHP (4-5):
http://uk.php.net/manual/en/migration5.incompatible.php

Almost all PHP4 code works perfectly in PHP5. I have to say, that's
definitely lousy backward compatibility isn't it?


> > 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.

I'm looking at the online version, the version you'd expect to be up-
to-date. The paragraph is contained here:
http://uk3.php.net/manual/en/language.types.string.php#langu age.types.string.casting

PHP 5.2 was introduced on the 2nd of November 2006. I hope you're not
suggesting that the online manual is suffering from 7 months of lag.


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

They say 'if applicable'. In addition to being vague, it infers that
there might be cases where __toString() isn't used. Cases where the
default 'Object' casting would be used can reasonably be assumed to
be: IN CASES WHERE __toString() IS NOT DEFINED.


> 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.

Good programmers might not leave it up to the compiler/interpreter,
but then again, good programmers could do this before they made it
fatal. You could always check a variable's type before using it in a
string context, there's no reasonable gain in usability by forcing it
on you. As a side note, breaking backward compatibility is just asking
for bugs too.


> > 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?

The crux of this argument is that __toString() shouldn't have to be
defined, therefore it wouldn't be a missing method. Again, the ONLINE
version. Would you like me to paste the URL again? I'll do that:
http://uk3.php.net/manual/en/language.types.string.php#langu age.types.string.casting


> > 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.

Converting to the string 'Object' is perfectly usable for me. It's
certainly not harmful. It'd be a FALSE COMFORT if there was a REAL
DANGER in converting an object to 'Object' but there isn't. My code
doesn't suddenly become HIGHLY UNSTABLE if I define __toString()
methods which return 'Object'.


> > 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.

You lose consistency - because whereas previously you could use any
variable type in a string context, you can no longer do that. The old
behaviour was not guesswork, you supplied an object in a string
context, it became 'Object'.


> 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.

I think one of your more serious mistakes is believing that an $object
variable is anything other than the internal type 'Object'. There is
no magical difference between the conversion of an array, a resource
or an object to a string. They all (or used to) return results
consistent with each other. Why doesn't PHP fatal on the following
code?


$a = new StdClass();
$b = new StdClass();

$c = $a + $b; // $c is now 2


PHP casts an object to an integer because it maintains the 'everything
can cast to an integer' premise.

Here's some more if you like:

$a = new StdClass();
$a->foo = 'bar';

var_dump($a);
var_dump((int)$a);
var_dump((bool)$a);
var_dump((float)$a);
var_dump((array)$a);
var_dump((object)$a);
var_dump((string)$a); // WHOOPS! FATAL


Now tell me that PHP causing a fatal unless you write __toString()
handlers improves consistency.

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

james.gauth@googlemail.com wrote:
> On 22 Jun, 02:15, Jerry Stuckle wrote:
>> james.ga...@googlemail.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.
>
> Well, since you're using such a convincing argument here, I'll just go
> ahead and refute your statement shall I? Here's the entire list of
> backward incompatible changes made from a MAJOR revision in PHP (4-5):
> http://uk.php.net/manual/en/migration5.incompatible.php
>
> Almost all PHP4 code works perfectly in PHP5. I have to say, that's
> definitely lousy backward compatibility isn't it?
>

First of all, I didn't say just from PHP4 to PHP5. I said in general.
This is just another incompatibility

Let's see... some of the major changes I recall off the top of my head...

Getting rid of short tags ( Dumping registered global vars
Changing long names ($HTTP_xxx_VARS)

Sure, these can still be used via PHP.INI settings - but not for much
longer. Also, please note I didn't say they SHOULDN'T be changed - but
they were changes which required major code rewrites. And some, like
the globals, still causes problems.

Also, things like new constructor names between PHP 4 and PHP 5 will
eventually cause problems. They work for now - but again, not forever.

And how about changing the mysql interface? The say things are going,
mysql_xx calls will go away in some future release and you'll have to
change all of those calls to mysqli_xx calls.

And there have been a lot more.

I know PHP is in transition - and many of these changes needed to be
made. But they required major rewrites of code. They wouldn't have if
the language had been better planned from the start.

>
>>> 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.
>
> I'm looking at the online version, the version you'd expect to be up-
> to-date. The paragraph is contained here:
> http://uk3.php.net/manual/en/language.types.string.php#langu age.types.string.casting
>
> PHP 5.2 was introduced on the 2nd of November 2006. I hope you're not
> suggesting that the online manual is suffering from 7 months of lag.
>

Yes, but you took the statement out of context. When it says it will
use the __tostring() method if applicable, it is talking about if that
is an object vs. some other type. It says nothing about whether the
system provides a __tostring() function or not.

>
>> Irregardless, they do say they will use the __tostring() method, if
>> available.
>
> They say 'if applicable'. In addition to being vague, it infers that
> there might be cases where __toString() isn't used. Cases where the
> default 'Object' casting would be used can reasonably be assumed to
> be: IN CASES WHERE __toString() IS NOT DEFINED.
>

Sure, it doesn't use __tostring() if it's not dealing with an object,
i.e. a numeric value or a resource.

And I see no reason to infer that this would cause a cast to the default
Object class.

>
>> 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.
>
> Good programmers might not leave it up to the compiler/interpreter,
> but then again, good programmers could do this before they made it
> fatal. You could always check a variable's type before using it in a
> string context, there's no reasonable gain in usability by forcing it
> on you. As a side note, breaking backward compatibility is just asking
> for bugs too.
>

As I said above, there are numerous instances of much more severe
changes which break backward compatibility.

>
>>> 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?
>
> The crux of this argument is that __toString() shouldn't have to be
> defined, therefore it wouldn't be a missing method. Again, the ONLINE
> version. Would you like me to paste the URL again? I'll do that:
> http://uk3.php.net/manual/en/language.types.string.php#langu age.types.string.casting
>

I can read. Maybe it shouldn't have been defined in the first place. I
tend to agree it shouldn't have been. But now they are correcting this
problem - like they've corrected other "problems" in the past.

>
>>> 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.
>
> Converting to the string 'Object' is perfectly usable for me. It's
> certainly not harmful. It'd be a FALSE COMFORT if there was a REAL
> DANGER in converting an object to 'Object' but there isn't. My code
> doesn't suddenly become HIGHLY UNSTABLE if I define __toString()
> methods which return 'Object'.
>

Fine, then create a __tostring() function which returns an Object.

>
>>> 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.
>
> You lose consistency - because whereas previously you could use any
> variable type in a string context, you can no longer do that. The old
> behaviour was not guesswork, you supplied an object in a string
> context, it became 'Object'.
>

Sure you can - as long as you define a __tostring() function for the
class. No problem. Are you saying this is too hard for you to do?

>
>> 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.
>
> I think one of your more serious mistakes is believing that an $object
> variable is anything other than the internal type 'Object'. There is
> no magical difference between the conversion of an array, a resource
> or an object to a string. They all (or used to) return results
> consistent with each other. Why doesn't PHP fatal on the following
> code?
>

Sure there is. An array or a resource are PHP-defined types. A
user-defined object is not. Huge difference. The PHP compiler can
handle PHP defined types. Effectively you can consider PHP has a
__tostring() function already built in for these types.

>
> $a = new StdClass();
> $b = new StdClass();
>
> $c = $a + $b; // $c is now 2
>
>
> PHP casts an object to an integer because it maintains the 'everything
> can cast to an integer' premise.
>
> Here's some more if you like:
>
> $a = new StdClass();
> $a->foo = 'bar';
>
> var_dump($a);
> var_dump((int)$a);
> var_dump((bool)$a);
> var_dump((float)$a);
> var_dump((array)$a);
> var_dump((object)$a);
> var_dump((string)$a); // WHOOPS! FATAL
>
>
> Now tell me that PHP causing a fatal unless you write __toString()
> handlers improves consistency.
>

Your fatal error looks perfectly fine to me. Maybe eventually they will
fix the other errors which allow invalid casting, also.

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

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

On 26 Jun, 23:29, Jerry Stuckle wrote:
> james.ga...@googlemail.com wrote:
> > On 22 Jun, 02:15, Jerry Stuckle wrote:
>
> I know PHP is in transition - and many of these changes needed to be
> made. But they required major rewrites of code. They wouldn't have if
> the language had been better planned from the start.

This is exactly the point, better planning. A half-baked operator
overloading scheme which breaks backward compatibility is not
evolution, it's feature creep.

There are two better options that they could've considered:
a) Implement operator overloading in its entirety and allow the base
object prototype to be overloaded
b) Implement this system but only issue a notice or a warning when a
__toString() method is not found


> >>> 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.
>
> Yes, but you took the statement out of context. When it says it will
> use the __tostring() method if applicable, it is talking about if that
> is an object vs. some other type. It says nothing about whether the
> system provides a __tostring() function or not.

The documentation is already marked as a bug here so I guess the
designers agree that it's vague:
http://bugs.php.net/bug.php?id=3D41750


> >> 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.
>
> > Good programmers might not leave it up to the compiler/interpreter,
> > but then again, good programmers could do this before they made it
> > fatal. You could always check a variable's type before using it in a
> > string context, there's no reasonable gain in usability by forcing it
> > on you. As a side note, breaking backward compatibility is just asking
> > for bugs too.
>
> As I said above, there are numerous instances of much more severe
> changes which break backward compatibility.

The numerous instances you mentioned all had very long deprecation
periods and a way to turn the old functionality back on again. If we
change our APIs we notify our clients and provide them a sufficient
amount of time to change their code. No notification was made and no
deprecation period was given.


> > Converting to the string 'Object' is perfectly usable for me. It's
> > certainly not harmful. It'd be a FALSE COMFORT if there was a REAL
> > DANGER in converting an object to 'Object' but there isn't. My code
> > doesn't suddenly become HIGHLY UNSTABLE if I define __toString()
> > methods which return 'Object'.
>
> Fine, then create a __tostring() function which returns an Object.

Try doing that with StdClass.


> >>> 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.
>
> > You lose consistency - because whereas previously you could use any
> > variable type in a string context, you can no longer do that. The old
> > behaviour was not guesswork, you supplied an object in a string
> > context, it became 'Object'.
>
> Sure you can - as long as you define a __tostring() function for the
> class. No problem. Are you saying this is too hard for you to do?

You can't define __toString() methods for PHP built-in objects. You
can't fill an array with a mixed set of variables and pass it to
implode() if it contains a PHP built-in object.

I'm saying that in some dark recess of some dark hole there's bound to
be a library which I have no control over which makes use of an object
in a string context and causes a fatal error in a place where it would
be innocuous to simply convert it to 'Object'. Here we go, here's some
code in WURFL (wurfl.sourceforge.net):

function _toLog($func, $text, $requestedLogLevel=3DLOG_NOTICE){
global $wurfl_conf;

if ( !defined('LOG_LEVEL') || LOG_LEVEL == 0 ) {
return;
}
if ( $requestedLogLevel == LOG_ERR ) {
$warn_banner =3D 'ERROR: ';
} else if ( $requestedLogLevel == LOG_WARNING ) {
$warn_banner =3D 'WARNING: ';
} else {
$warn_banner =3D '';
}
//echo "Opening ".$wurfl_conf['WURFL_LOG_FILE']."
\n";
$uname =3D posix_uname();
$_textToLog =3D date('r')." [".$uname['nodename']."
"posix_getpid()."]"."[$func] ".$warn_banner . $text;
$_logFP =3D fopen($wurfl_conf['WURFL_LOG_FILE'], "a+");
fputs($_logFP, $_textToLog."\n");
fclose($_logFP);
return;
}

Which is more appropriate: Breaking code like this (leading to
possible database inconsistency, or any other amount of problems from
a mid-execution fatal) or issuing a warning and retaining the old
functionality?


> An array or a resource are PHP-defined types. A
> user-defined object is not. Huge difference. The PHP compiler can
> handle PHP defined types.

An instantiation of a user defined class is a variable of the type
'Object'. It's still a PHP-defined type, just because you populate an
object with data or attach functions to a class doesn't change that.
Explain the huge difference because I really must be missing something
here.


> >
> > $a =3D new StdClass();
> > $b =3D new StdClass();
>
> > $c =3D $a + $b; // $c is now 2
> >
>
> > PHP casts an object to an integer because it maintains the 'everything
> > can cast to an integer' premise.
>
> > Here's some more if you like:
> >
> > $a =3D new StdClass();
> > $a->foo =3D 'bar';
>
> > var_dump($a);
> > var_dump((int)$a);
> > var_dump((bool)$a);
> > var_dump((float)$a);
> > var_dump((array)$a);
> > var_dump((object)$a);
> > var_dump((string)$a); // WHOOPS! FATAL
> >
>
> > Now tell me that PHP causing a fatal unless you write __toString()
> > handlers improves consistency.
>
> Your fatal error looks perfectly fine to me. Maybe eventually they will
> fix the other errors which allow invalid casting, also.

Yeah, and maybe eventually they'll drop the whole loosely typed
fa=E7ade, implement namespaces and rename the language Java.

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

james.gauth@googlemail.com wrote:
> On 26 Jun, 23:29, Jerry Stuckle wrote:
>> james.ga...@googlemail.com wrote:
>>> On 22 Jun, 02:15, Jerry Stuckle wrote:
>> I know PHP is in transition - and many of these changes needed to be
>> made. But they required major rewrites of code. They wouldn't have if
>> the language had been better planned from the start.
>
> This is exactly the point, better planning. A half-baked operator
> overloading scheme which breaks backward compatibility is not
> evolution, it's feature creep.
>
> There are two better options that they could've considered:
> a) Implement operator overloading in its entirety and allow the base
> object prototype to be overloaded

That would be a major change to the language. Not that I'm against it -
I love it in C++ and miss it in Java. But I've also seen it abused more
than used (properly, that is).

> b) Implement this system but only issue a notice or a warning when a
> __toString() method is not found
>

And do what when the method is not found? I prefer the "clean cut".
You only need to change things once, and people won't forget about it in
new code.

Your way people will just ignore the notice and at some later time will
get caught.

>
>>>>> 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.
>> Yes, but you took the statement out of context. When it says it will
>> use the __tostring() method if applicable, it is talking about if that
>> is an object vs. some other type. It says nothing about whether the
>> system provides a __tostring() function or not.
>
> The documentation is already marked as a bug here so I guess the
> designers agree that it's vague:
> http://bugs.php.net/bug.php?id=41750
>

OK, I don't read it that way. But OTOH I grew up in the IBM world,
where such doc is the norm :-)

>
>>>> 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.
>>> Good programmers might not leave it up to the compiler/interpreter,
>>> but then again, good programmers could do this before they made it
>>> fatal. You could always check a variable's type before using it in a
>>> string context, there's no reasonable gain in usability by forcing it
>>> on you. As a side note, breaking backward compatibility is just asking
>>> for bugs too.
>> As I said above, there are numerous instances of much more severe
>> changes which break backward compatibility.
>
> The numerous instances you mentioned all had very long deprecation
> periods and a way to turn the old functionality back on again. If we
> change our APIs we notify our clients and provide them a sufficient
> amount of time to change their code. No notification was made and no
> deprecation period was given.
>

You didn't say anything about "very long deprecation periods". You
spoke only of incompatibilities. I mentioned several which required
major rewrites of the code.

IMHO It would have been much better to make a clean cut on each of
these, also. Just search through the forum here. There are all kinds
of examples of people writing NEW CODE requiring register_globals to be
on. The same is true with short tags, for instance.

Creating a long deprecation period doesn't solve the problem - it just
delays it. And since new code also uses those deprecated features, the
longer the deprecation period the worse the problem gets.

>
>>> Converting to the string 'Object' is perfectly usable for me. It's
>>> certainly not harmful. It'd be a FALSE COMFORT if there was a REAL
>>> DANGER in converting an object to 'Object' but there isn't. My code
>>> doesn't suddenly become HIGHLY UNSTABLE if I define __toString()
>>> methods which return 'Object'.
>> Fine, then create a __tostring() function which returns an Object.
>
> Try doing that with StdClass.
>

Why?

Actually, it would be incorrect to have a __tostring() function which
returns an object. It needs to return a string.


>
>>>>> 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.
>>> You lose consistency - because whereas previously you could use any
>>> variable type in a string context, you can no longer do that. The old
>>> behaviour was not guesswork, you supplied an object in a string
>>> context, it became 'Object'.
>> Sure you can - as long as you define a __tostring() function for the
>> class. No problem. Are you saying this is too hard for you to do?
>
> You can't define __toString() methods for PHP built-in objects. You
> can't fill an array with a mixed set of variables and pass it to
> implode() if it contains a PHP built-in object.
>

Gee, you know, the same is true for C++ and Java. But you can extend a
PHP built-in object and add your own __tostring() function to it.
Pretty simple.

> I'm saying that in some dark recess of some dark hole there's bound to
> be a library which I have no control over which makes use of an object
> in a string context and causes a fatal error in a place where it would
> be innocuous to simply convert it to 'Object'. Here we go, here's some
> code in WURFL (wurfl.sourceforge.net):
>
> function _toLog($func, $text, $requestedLogLevel=LOG_NOTICE){
> global $wurfl_conf;
>
> if ( !defined('LOG_LEVEL') || LOG_LEVEL == 0 ) {
> return;
> }
> if ( $requestedLogLevel == LOG_ERR ) {
> $warn_banner = 'ERROR: ';
> } else if ( $requestedLogLevel == LOG_WARNING ) {
> $warn_banner = 'WARNING: ';
> } else {
> $warn_banner = '';
> }
> //echo "Opening ".$wurfl_conf['WURFL_LOG_FILE']."
\n";
> $uname = posix_uname();
> $_textToLog = date('r')." [".$uname['nodename']."
> ".posix_getpid()."]"."[$func] ".$warn_banner . $text;
> $_logFP = fopen($wurfl_conf['WURFL_LOG_FILE'], "a+");
> fputs($_logFP, $_textToLog."\n");
> fclose($_logFP);
> return;
> }
>
> Which is more appropriate: Breaking code like this (leading to
> possible database inconsistency, or any other amount of problems from
> a mid-execution fatal) or issuing a warning and retaining the old
> functionality?
>

I would much rather see the error so I could fix the problem properly.

But where is this using a predefined __tostring() function, anyway? I
don't see it. So the question is irrelevant.

>
>> An array or a resource are PHP-defined types. A
>> user-defined object is not. Huge difference. The PHP compiler can
>> handle PHP defined types.
>
> An instantiation of a user defined class is a variable of the type
> 'Object'. It's still a PHP-defined type, just because you populate an
> object with data or attach functions to a class doesn't change that.
> Explain the huge difference because I really must be missing something
> here.
>

No, it is no longer a PHP-defined type. It is a user-defined type. It
may be derived from a PHP-defined type, but that does not make it
PHP-defined.


>
>>>
>>> $a = new StdClass();
>>> $b = new StdClass();
>>> $c = $a + $b; // $c is now 2
>>>
>>> PHP casts an object to an integer because it maintains the 'everything
>>> can cast to an integer' premise.
>>> Here's some more if you like:
>>>
>>> $a = new StdClass();
>>> $a->foo = 'bar';
>>> var_dump($a);
>>> var_dump((int)$a);
>>> var_dump((bool)$a);
>>> var_dump((float)$a);
>>> var_dump((array)$a);
>>> var_dump((object)$a);
>>> var_dump((string)$a); // WHOOPS! FATAL
>>>
>>> Now tell me that PHP causing a fatal unless you write __toString()
>>> handlers improves consistency.
>> Your fatal error looks perfectly fine to me. Maybe eventually they will
>> fix the other errors which allow invalid casting, also.
>
> Yeah, and maybe eventually they'll drop the whole loosely typed
> façade, implement namespaces and rename the language Java.
>

What an asinine comment.


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

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

On 27 Jun, 14:32, Jerry Stuckle wrote:
> Creating a long deprecation period doesn't solve the problem - it just
> delays it. And since new code also uses those deprecated features, the
> longer the deprecation period the worse the problem gets.

It delays the problem so that appropriate action can be taken without
breaking backward compatibility, that's the point of deprecation. I
keep track of the PHP change log, I scan for things that are likely to
impact my code. If you write new code using deprecated features then
you're asking for problems and that's not what I'm advocating here.

> > I'm saying that in some dark recess of some dark hole there's bound to
> > be a library which I have no control over which makes use of an object
> > in a string context and causes a fatal error in a place where it would
> > be innocuous to simply convert it to 'Object'. Here we go, here's some
> > code in WURFL (wurfl.sourceforge.net):
>
> > function _toLog($func, $text, $requestedLogLevel=3DLOG_NOTICE){
> > global $wurfl_conf;
>
> > if ( !defined('LOG_LEVEL') || LOG_LEVEL == 0 ) {
> > return;
> > }
> > if ( $requestedLogLevel == LOG_ERR ) {
> > $warn_banner =3D 'ERROR: ';
> > } else if ( $requestedLogLevel == LOG_WARNING ) {
> > $warn_banner =3D 'WARNING: ';
> > } else {
> > $warn_banner =3D '';
> > }
> > //echo "Opening ".$wurfl_conf['WURFL_LOG_FILE']."
\n";
> > $uname =3D posix_uname();
> > $_textToLog =3D date('r')." [".$uname['nodename']."
> > ".posix_getpid()."]"."[$func] ".$warn_banner . $text;
> > $_logFP =3D fopen($wurfl_conf['WURFL_LOG_FILE'], "a+");
> > fputs($_logFP, $_textToLog."\n");
> > fclose($_logFP);
> > return;
> > }
>
> > Which is more appropriate: Breaking code like this (leading to
> > possible database inconsistency, or any other amount of problems from
> > a mid-execution fatal) or issuing a warning and retaining the old
> > functionality?
>
> I would much rather see the error so I could fix the problem properly.

Anyone who checks their error log frequently would be aware of the
error. You'd rather have your program crash than have your program
issue a warning.

> But where is this using a predefined __tostring() function, anyway? I
> don't see it. So the question is irrelevant.

This is what I was hoping you'd write. The error in this function is
that it assumes the arguments are clean before being passed to it. The
code should have checked the types of the arguments before using them
in a string context. The problem is not apparent until the code bails.

> No, it is no longer a PHP-defined type. It is a user-defined type. It
> may be derived from a PHP-defined type, but that does not make it
> PHP-defined.

Please explain why the PHP compiler can handle PHP-defined types but
user-defined (in your definition) types need to be treated
differently.

> > Yeah, and maybe eventually they'll drop the whole loosely typed
> > fa=E7ade, implement namespaces and rename the language Java.
>
> What an asinine comment.

Asinine maybe, but when you start having to type-check *everything*
instead of having fixed-types from the outset the advantages of a
loosely-typed language whittle away.

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

james.gauth@googlemail.com wrote:
> On 27 Jun, 14:32, Jerry Stuckle wrote:
>> Creating a long deprecation period doesn't solve the problem - it just
>> delays it. And since new code also uses those deprecated features, the
>> longer the deprecation period the worse the problem gets.
>
> It delays the problem so that appropriate action can be taken without
> breaking backward compatibility, that's the point of deprecation. I
> keep track of the PHP change log, I scan for things that are likely to
> impact my code. If you write new code using deprecated features then
> you're asking for problems and that's not what I'm advocating here.

And as I said - it increases the problem because new code IS still being
written to the deprecated functions. Check out past posts in this newsgroup!

At least in Java you get a compiler warning that the method has been
deprecated.

>
>>> I'm saying that in some dark recess of some dark hole there's bound to
>>> be a library which I have no control over which makes use of an object
>>> in a string context and causes a fatal error in a place where it would
>>> be innocuous to simply convert it to 'Object'. Here we go, here's some
>>> code in WURFL (wurfl.sourceforge.net):
>>> function _toLog($func, $text, $requestedLogLevel=LOG_NOTICE){
>>> global $wurfl_conf;
>>> if ( !defined('LOG_LEVEL') || LOG_LEVEL == 0 ) {
>>> return;
>>> }
>>> if ( $requestedLogLevel == LOG_ERR ) {
>>> $warn_banner = 'ERROR: ';
>>> } else if ( $requestedLogLevel == LOG_WARNING ) {
>>> $warn_banner = 'WARNING: ';
>>> } else {
>>> $warn_banner = '';
>>> }
>>> //echo "Opening ".$wurfl_conf['WURFL_LOG_FILE']."
\n";
>>> $uname = posix_uname();
>>> $_textToLog = date('r')." [".$uname['nodename']."
>>> ".posix_getpid()."]"."[$func] ".$warn_banner . $text;
>>> $_logFP = fopen($wurfl_conf['WURFL_LOG_FILE'], "a+");
>>> fputs($_logFP, $_textToLog."\n");
>>> fclose($_logFP);
>>> return;
>>> }
>>> Which is more appropriate: Breaking code like this (leading to
>>> possible database inconsistency, or any other amount of problems from
>>> a mid-execution fatal) or issuing a warning and retaining the old
>>> functionality?
>> I would much rather see the error so I could fix the problem properly.
>
> Anyone who checks their error log frequently would be aware of the
> error. You'd rather have your program crash than have your program
> issue a warning.
>

Many people, especially on shared hosts, have no access to their error
logs. I do because I have VPS's. But not everyone does.

And yes, I'd much rather have the program crash when there is a problem.

>> But where is this using a predefined __tostring() function, anyway? I
>> don't see it. So the question is irrelevant.
>
> This is what I was hoping you'd write. The error in this function is
> that it assumes the arguments are clean before being passed to it. The
> code should have checked the types of the arguments before using them
> in a string context. The problem is not apparent until the code bails.
>

It is the programmer's responsibility to make sure the parameters are
clean before being passed to it.

Why should 99.9999% of the calls to a functions have decreased
performance because 0.0001% of the calls aren't correct?

This is how C and C++ do it - which is a major part of their efficiency.
And this is how most of the PHP functions work.

>> No, it is no longer a PHP-defined type. It is a user-defined type. It
>> may be derived from a PHP-defined type, but that does not make it
>> PHP-defined.
>
> Please explain why the PHP compiler can handle PHP-defined types but
> user-defined (in your definition) types need to be treated
> differently.
>

Because the compiler built the PHP types and can define appropriate
default actions for them. It does not create user-defined types, and
cannot make an intelligent decision on how to create an appropriate
action for them.

From your argument, you shouldn't need to build a constructor for your
classes, either. The compiler should know how to initialize your
user-defined variables without any help. And you shouldn't need a
destructor; if there is any action you class needs to undo, the compiler
should understand that and be able to do it for you.

>>> Yeah, and maybe eventually they'll drop the whole loosely typed
>>> façade, implement namespaces and rename the language Java.
>> What an asinine comment.
>
> Asinine maybe, but when you start having to type-check *everything*
> instead of having fixed-types from the outset the advantages of a
> loosely-typed language whittle away.
>

No need to type-check everything. All you need to do is define a
__tostring() function if you want to convert the object to a string.

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

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

On 27 Jun, 17:15, Jerry Stuckle wrote:
> james.ga...@googlemail.com wrote:
> > On 27 Jun, 14:32, Jerry Stuckle wrote:
> >> Creating a long deprecation period doesn't solve the problem - it just
> >> delays it. And since new code also uses those deprecated features, the
> >> longer the deprecation period the worse the problem gets.
>
> > It delays the problem so that appropriate action can be taken without
> > breaking backward compatibility, that's the point of deprecation. I
> > keep track of the PHP change log, I scan for things that are likely to
> > impact my code. If you write new code using deprecated features then
> > you're asking for problems and that's not what I'm advocating here.
>
> And as I said - it increases the problem because new code IS still being
> written to the deprecated functions. Check out past posts in this newsgro=
up!

I've seen them, register_globals etc. Just because people write new
code using deprecated functions shouldn't mean that people who follow
proper code maintenance practices should suffer.

> At least in Java you get a compiler warning that the method has been
> deprecated.

Exactly, you'd get a runtime warning that the method you are using is
deprecated.

> > Anyone who checks their error log frequently would be aware of the
> > error. You'd rather have your program crash than have your program
> > issue a warning.
>
> Many people, especially on shared hosts, have no access to their error
> logs. I do because I have VPS's. But not everyone does.

If you didn't have access to the error log your program would crash
and you wouldn't know the reason for it anyway.

> And yes, I'd much rather have the program crash when there is a problem.

Then I hope your programs release database locks before they do their
crashing.


> >> But where is this using a predefined __tostring() function, anyway? I
> >> don't see it. So the question is irrelevant.
>
> > This is what I was hoping you'd write. The error in this function is
> > that it assumes the arguments are clean before being passed to it. The
> > code should have checked the types of the arguments before using them
> > in a string context. The problem is not apparent until the code bails.
>
> It is the programmer's responsibility to make sure the parameters are
> clean before being passed to it.

No, it's the function's responsibility to ensure data passed to it is
clean.

> Why should 99.9999% of the calls to a functions have decreased
> performance because 0.0001% of the calls aren't correct?
>
> This is how C and C++ do it - which is a major part of their efficiency.
> And this is how most of the PHP functions work.

C and C++ do it by fixed typing, PHP gets around it by multiple if
statements.

> >> No, it is no longer a PHP-defined type. It is a user-defined type. It
> >> may be derived from a PHP-defined type, but that does not make it
> >> PHP-defined.
>
> > Please explain why the PHP compiler can handle PHP-defined types but
> > user-defined (in your definition) types need to be treated
> > differently.
>
> Because the compiler built the PHP types and can define appropriate
> default actions for them. It does not create user-defined types, and
> cannot make an intelligent decision on how to create an appropriate
> action for them.
>
> From your argument, you shouldn't need to build a constructor for your
> classes, either. The compiler should know how to initialize your
> user-defined variables without any help. And you shouldn't need a
> destructor; if there is any action you class needs to undo, the compiler
> should understand that and be able to do it for you.

There's a large amount of automation applied to PHP objects. By your
argument you shouldn't need to define protected object properties, you
should build a layer to implement them yourself.


> >>> Yeah, and maybe eventually they'll drop the whole loosely typed
> >>> fa=E7ade, implement namespaces and rename the language Java.
> >> What an asinine comment.
>
> > Asinine maybe, but when you start having to type-check *everything*
> > instead of having fixed-types from the outset the advantages of a
> > loosely-typed language whittle away.
>
> No need to type-check everything. All you need to do is define a
> __tostring() function if you want to convert the object to a string.

If you are aware that using a variable from outside a function may
result in a fatal error, you are obligated to type-check it before
using it.

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

james.gauth@googlemail.com wrote:
> On 27 Jun, 17:15, Jerry Stuckle wrote:
>> james.ga...@googlemail.com wrote:
>>> On 27 Jun, 14:32, Jerry Stuckle wrote:
>>>> Creating a long deprecation period doesn't solve the problem - it just
>>>> delays it. And since new code also uses those deprecated features, the
>>>> longer the deprecation period the worse the problem gets.
>>> It delays the problem so that appropriate action can be taken without
>>> breaking backward compatibility, that's the point of deprecation. I
>>> keep track of the PHP change log, I scan for things that are likely to
>>> impact my code. If you write new code using deprecated features then
>>> you're asking for problems and that's not what I'm advocating here.
>> And as I said - it increases the problem because new code IS still being
>> written to the deprecated functions. Check out past posts in this newsgroup!
>
> I've seen them, register_globals etc. Just because people write new
> code using deprecated functions shouldn't mean that people who follow
> proper code maintenance practices should suffer.
>

They aren't suffering. They will need to change the code sooner or
later. The choices are to upgrade and do it now, or keep putting it off
for years until the code has been modified several more times and is
harder to modify.

>> At least in Java you get a compiler warning that the method has been
>> deprecated.
>
> Exactly, you'd get a runtime warning that the method you are using is
> deprecated.
>
>>> Anyone who checks their error log frequently would be aware of the
>>> error. You'd rather have your program crash than have your program
>>> issue a warning.
>> Many people, especially on shared hosts, have no access to their error
>> logs. I do because I have VPS's. But not everyone does.
>
> If you didn't have access to the error log your program would crash
> and you wouldn't know the reason for it anyway.
>

True - but at least you know you have a problem and can enable the error
display.

>> And yes, I'd much rather have the program crash when there is a problem.
>
> Then I hope your programs release database locks before they do their
> crashing.
>

Not a problem. It's called project management and quality control.

>
>>>> But where is this using a predefined __tostring() function, anyway? I
>>>> don't see it. So the question is irrelevant.
>>> This is what I was hoping you'd write. The error in this function is
>>> that it assumes the arguments are clean before being passed to it. The
>>> code should have checked the types of the arguments before using them
>>> in a string context. The problem is not apparent until the code bails.
>> It is the programmer's responsibility to make sure the parameters are
>> clean before being passed to it.
>
> No, it's the function's responsibility to ensure data passed to it is
> clean.
>

Sorry, basic difference in philosophy. This is going back to Basic and
other languages.

>> Why should 99.9999% of the calls to a functions have decreased
>> performance because 0.0001% of the calls aren't correct?
>>
>> This is how C and C++ do it - which is a major part of their efficiency.
>> And this is how most of the PHP functions work.
>
> C and C++ do it by fixed typing, PHP gets around it by multiple if
> statements.
>

True. But you can still pass improper parameters in C/C++. And the
function will not check for it. Again - it's the programmer's
responsibility to ensure his code is right. All the function should
have to do is perform its job when the correct parameters are passed.

>>>> No, it is no longer a PHP-defined type. It is a user-defined type. It
>>>> may be derived from a PHP-defined type, but that does not make it
>>>> PHP-defined.
>>> Please explain why the PHP compiler can handle PHP-defined types but
>>> user-defined (in your definition) types need to be treated
>>> differently.
>> Because the compiler built the PHP types and can define appropriate
>> default actions for them. It does not create user-defined types, and
>> cannot make an intelligent decision on how to create an appropriate
>> action for them.
>>
>> From your argument, you shouldn't need to build a constructor for your
>> classes, either. The compiler should know how to initialize your
>> user-defined variables without any help. And you shouldn't need a
>> destructor; if there is any action you class needs to undo, the compiler
>> should understand that and be able to do it for you.
>
> There's a large amount of automation applied to PHP objects. By your
> argument you shouldn't need to define protected object properties, you
> should build a layer to implement them yourself.
>

I said nothing about protected properties, and they have nothing to do
with the discussion.

>
>>>>> Yeah, and maybe eventually they'll drop the whole loosely typed
>>>>> façade, implement namespaces and rename the language Java.
>>>> What an asinine comment.
>>> Asinine maybe, but when you start having to type-check *everything*
>>> instead of having fixed-types from the outset the advantages of a
>>> loosely-typed language whittle away.
>> No need to type-check everything. All you need to do is define a
>> __tostring() function if you want to convert the object to a string.
>
> If you are aware that using a variable from outside a function may
> result in a fatal error, you are obligated to type-check it before
> using it.
>

Nope. Not at all.

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

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

On Jun 11, 6:46 am, phpCodeHead wrote:
> Code which should allow my constructor to accept arguments:
>
> > class Person {
> function __construct($name)
> {
> $this->name =3D $name;
> }
>
> function getName()
> {
> return $this->name;
> }
>
> function printName()
> {
> print $this->name;
> }
>
> private $name;
> }
>
> $judy =3D new Person("Judy") . "\n"; // <- this is line parser d=
on't
> like
> $joe =3D new Person("Joe") . "\n";
>
> $judy->printName() . '
';
> $joe->printName() . '
';
> ?>
>
> 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




Hello

Just saw this message, you probably solved it... But for future
reference of other users :


$judy =3D new Person("Judy") . "\n"


This line gives error because :

$var =3D Object + String

You should just do

$judy =3D new Person("Judy");

don't quite understand why you put the newline in there :)

after that you can do
$judy->printName() . '
'
thats no problem, because your method printName() returns a string
so string + string works.

though your way of doing isn't very clean. doing a function that does
a print then adding a
after that ..

i'd do something like :

$judy =3D new Person("Judy");

print $judy->getName() . "
";

or have the printName() method do some formatting on it so you don't
need to do it in the code :)



Hope that helped someone ...

Laurent d'Hav=E9