php-general Digest 16 Dec 2010 23:51:01 -0000 Issue 7090
Topics (messages 310071 through 310093):
Re: How does one reply to messages on this list?
310071 by: João Cândido de Souza Neto
310072 by: Daniel Brown
310074 by: Nicholas Kell
310075 by: Jay Blanchard
310076 by: Daniel Brown
310077 by: Nicholas Kell
310078 by: Paul M Foster
310079 by: Nicholas Kell
310080 by: Govinda
310081 by: Daniel Molina Wegener
310082 by: David Harkness
310083 by: Jay Blanchard
PHP 5.2.16 Released!
310073 by: Ilia Alshanetsky
String passed to object constructor turning into an instance of that object?
310084 by: Kris Deugau
310085 by: Tommy Pham
310086 by: Kris Deugau
310087 by: Nathan Nobbe
310088 by: Kris Deugau
310089 by: Nathan Nobbe
310090 by: David Harkness
310091 by: Kris Deugau
310092 by: Nathan Nobbe
310093 by: David Harkness
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
As I use outlook, I just hit "Reply to Group.
--
João Cândido de Souza Neto
"Sam Smith" <[email protected]> escreveu na mensagem
news:[email protected]...
> If I just hit 'Reply' I'll send my reply to the individual who created the
> message. If I hit 'Reply All' my reply will be sent to: Govinda <
> [email protected]>, PHP-General List
> <[email protected]>
> and the creator of the message.
>
> Neither option seems correct. What's up with that?
>
> Thanks
>
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 06:44, Sam Smith <[email protected]> wrote:
> If I just hit 'Reply' I'll send my reply to the individual who created the
> message. If I hit 'Reply All' my reply will be sent to: Govinda <
> [email protected]>, PHP-General List <[email protected]>
> and the creator of the message.
>
> Neither option seems correct. What's up with that?
With our lists (the PHP lists, that is), like many others, we ask
that you always hit "Reply-All" unless you intend to reply personally
to an individual. In general, the folks to whom you're replying will
be subscribers to the list to which you're writing anyway, and
[almost] all modern email clients and services will intelligently
discard duplicate messages if it's detected to be from a mailing list
or similar method of distribution.
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
Couldn't we just have a reply-to address for the list in the header of the
email? So all a fella had to do was hit reply, and it would work?
This is how the Apache and the MySQL list works. The PHP list is the only list
that I have to manually edit my reply every time.
For example, I hit reply all on this message, it is now replying to Daniel, and
CC'ing Sam and the php-general.
On Dec 16, 2010, at 5:55 AM, Daniel Brown wrote:
> On Thu, Dec 16, 2010 at 06:44, Sam Smith <[email protected]> wrote:
>> If I just hit 'Reply' I'll send my reply to the individual who created the
>> message. If I hit 'Reply All' my reply will be sent to: Govinda <
>> [email protected]>, PHP-General List <[email protected]>
>> and the creator of the message.
>>
>> Neither option seems correct. What's up with that?
>
> With our lists (the PHP lists, that is), like many others, we ask
> that you always hit "Reply-All" unless you intend to reply personally
> to an individual. In general, the folks to whom you're replying will
> be subscribers to the list to which you're writing anyway, and
> [almost] all modern email clients and services will intelligently
> discard duplicate messages if it's detected to be from a mailing list
> or similar method of distribution.
>
> --
> </Daniel P. Brown>
> Network Infrastructure Manager
> Documentation, Webmaster Teams
> http://www.php.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
[snip]
Couldn't we just have a reply-to address for the list in the header of
the email? So all a fella had to do was hit reply, and it would work?
This is how the Apache and the MySQL list works. The PHP list is the
only list that I have to manually edit my reply every time.
For example, I hit reply all on this message, it is now replying to
Daniel, and CC'ing Sam and the php-general.
[/snip]
Oh crap, here we go again. STFA, this comes up a couple of times an
annum.
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 09:19, Nicholas Kell <[email protected]> wrote:
>
> Couldn't we just have a reply-to address for the list in the header of the
> email? So all a fella had to do was hit reply, and it would work?
The easiest (and most accurate) answer: no.
> This is how the Apache and the MySQL list works. The PHP list is the only
> list that I have to manually edit my reply every time.
Actually, MySQL does not work that way. And it's been several
years since I posted to any of the Apache lists, but I do seem to
remember that being the case there. It was annoying. It's so much
more intuitive to know that hitting "Reply" goes to the individual,
whereas "Reply-All" will, as the option suggests, reply to all.
> For example, I hit reply all on this message, it is now replying to Daniel,
> and CC'ing Sam and the php-general.
Correct.... but what's the problem? We're all only receiving one
copy of the email, I'm sure. We've done it this way from the
beginning, and have no intention of changing it.
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
On Dec 16, 2010, at 8:26 AM, Daniel Brown wrote:
> On Thu, Dec 16, 2010 at 09:19, Nicholas Kell <[email protected]> wrote:
>>
>> Couldn't we just have a reply-to address for the list in the header of the
>> email? So all a fella had to do was hit reply, and it would work?
>
> The easiest (and most accurate) answer: no.
Ok.
>
>> This is how the Apache and the MySQL list works. The PHP list is the only
>> list that I have to manually edit my reply every time.
>
> Actually, MySQL does not work that way. And it's been several
> years since I posted to any of the Apache lists, but I do seem to
> remember that being the case there. It was annoying. It's so much
> more intuitive to know that hitting "Reply" goes to the individual,
> whereas "Reply-All" will, as the option suggests, reply to all.
I apologize, you are correct MySQL does not.
I guess to me it seemed intuitive that replying went to the list, considering
the list is where it (should have) came from. The sender only being a secondary
recipient. Also, knowing that I will more than likely never want to send
anything directly to the sender anyway.
>
>> For example, I hit reply all on this message, it is now replying to Daniel,
>> and CC'ing Sam and the php-general.
>
> Correct.... but what's the problem? We're all only receiving one
> copy of the email, I'm sure. We've done it this way from the
> beginning, and have no intention of changing it.
>
"We've done it this way from the
beginning" says it all.
No problem. I am not asking for the world to change. In fact I am not asking
for anything at all. I was just bringing to light a few things that I thought
were valuable to the OP's message.
I am using the latest Mac Mail on 10.6, and I do actually receive two copies of
the message whenever someone replies all. That is pretty annoying, but it's not
a big deal. I guess my client is not intelligently discarding duplicate
messages. Thank goodness it's not though, or I wouldn't know how to
repetitively test email sending when working on projects.
Every time that I replied to a message, I always took out the senders email and
entered the php-general email, but perhaps I was breaking protocol? I guess I
thought I was just being considerate to the sender, by not sending duplicate
messages. From now on I will hit reply all, and be done with it.
Bottom line - I am glad my email client gives me all the messages that are sent
to it, and nothing is going to (or needs to) change, so I suppose that this
message will, by some be considered spam.
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 08:19:52AM -0600, Nicholas Kell wrote:
>
> Couldn't we just have a reply-to address for the list in the header of
> the email? So all a fella had to do was hit reply, and it would work?
>
> This is how the Apache and the MySQL list works. The PHP list is the
> only list that I have to manually edit my reply every time.
>
> For example, I hit reply all on this message, it is now replying to
> Daniel, and CC'ing Sam and the php-general.
Lists to which one does not have to be subscribed to post are often set
up this way. My local Linux users group list does it the way you
suggest, because it's a closed list.
But the originators of any list set up things the way they believe is
best, and there's no benefit to arguing about it. There are heated
arguments about both ways of setting up a list, just like there are with
top- and bottom-posting. The final authority is the list admin for the
list you're posting to. And he's generally unsympathetic to opposing
viewpoints.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Dec 16, 2010, at 9:28 AM, Paul M Foster wrote:
> On Thu, Dec 16, 2010 at 08:19:52AM -0600, Nicholas Kell wrote:
>
>>
>> Couldn't we just have a reply-to address for the list in the header of
>> the email? So all a fella had to do was hit reply, and it would work?
>>
>> This is how the Apache and the MySQL list works. The PHP list is the
>> only list that I have to manually edit my reply every time.
>>
>> For example, I hit reply all on this message, it is now replying to
>> Daniel, and CC'ing Sam and the php-general.
>
> Lists to which one does not have to be subscribed to post are often set
> up this way. My local Linux users group list does it the way you
> suggest, because it's a closed list.
>
> But the originators of any list set up things the way they believe is
> best, and there's no benefit to arguing about it. There are heated
> arguments about both ways of setting up a list, just like there are with
> top- and bottom-posting. The final authority is the list admin for the
> list you're posting to. And he's generally unsympathetic to opposing
> viewpoints.
Sorry if I came off as argumentative, I didn't intend for that. I absolutely
agree that the admin has last word and generally unsympathetic to opposing
viewpoints.
I am compliant.
Let me give a formal apology to the list, for unscrewing the cap off the can of
worms.
I apologize, and you wont hear another word from me on this. Since, it is,
after all not a big deal to me. It's just an email list. This list has brought
better things to the table for many people than chattering about email list
preferences.
--- End Message ---
--- Begin Message ---
Let me give a formal apology to the list, for unscrewing the cap off
the can of worms.
NIcholas, just so you know you are appreciated for asking the Q in the
first place:
..some of us are new here.. or only lurk enough to catch some of the
threads... and so I was also missing some of the subtleties in how the
list send copies to whom, and why. Your Q, and the replies..
clarified much. Thank you!
-Govinda
--- End Message ---
--- Begin Message ---
On Thursday 16 December 2010,
Sam Smith <[email protected]> wrote:
> If I just hit 'Reply' I'll send my reply to the individual who created
> the message. If I hit 'Reply All' my reply will be sent to: Govinda <
> [email protected]>, PHP-General List
> <[email protected]> and the creator of the message.
>
> Neither option seems correct. What's up with that?
If your MUA (or email client) is smart enough, it should have at least
"Reply", "Reply to Sender", "Reply to All" and "Reply to Mailing List".
Here I have all those options.
>
> Thanks
Best regards,
--
Daniel Molina Wegener <dmw [at] coder [dot] cl>
System Programmer & Web Developer
Phone: +56 (2) 979-0277 | Blog: http://coder.cl/
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 8:09 AM, Daniel Molina Wegener <[email protected]> wrote:
> If your MUA (or email client) is smart enough, it should have at least
>
> "Reply", "Reply to Sender", "Reply to All" and "Reply to Mailing List".
>
To which my client adds "Reply to /dev/null", "Reply to Those Who Actually
Care", and "Reply to Al Gore". It's much smarter than the average MUA.
David
--- End Message ---
--- Begin Message ---
[snip]
To which my client adds "Reply to /dev/null", "Reply to Those Who
Actually
Care", and "Reply to Al Gore". It's much smarter than the average MUA.
[/snip]
It could be argued that replying to Al Gore might not be all that smart.
--- End Message ---
--- Begin Message ---
The PHP development team would like to announce the immediate
availability of PHP 5.2.16. This release marks the end of support for
PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
This release focuses on addressing a regression in open_basedir
implementation introduced in 5.2.15 in addition to fixing a crash
inside PDO::pgsql on data retrieval when the server is down. All users
who have upgraded to 5.2.15 and are utilizing open_basedir are
strongly encouraged to upgrade to 5.2.16 or 5.3.4.
For a full list of changes in PHP 5.2.16, see the ChangeLog on
<http://php.net/ChangeLog-5.php#5.2.16>. For source downloads please
visit our downloads page on <http://php.net/downloads.php>, Windows
binaries can be found on <http://windows.php.net/download/>.
Ilia Alshanetsky
5.2 Release Master
--- End Message ---
--- Begin Message ---
I'm in the process of migrating customer websites off an old legacy
server that's pushing EOL, and starting to show hardware failures.
One site is throwing errors on what, so far as I can tell, should be
perfectly working code.
The original code works fine on both CentOS 3 (PHP 4.3.2) and CentOS 4
(4.3.9); the "new" server is still a bit outdated (Debian etch plus
some backports and updates from lenny; PHP 5.2.0).
The site was designed by staff at a previous hosting company and uses a
combination of the Fusebox app framework (which seems to work OK, after
a few relatively minor fixes) and a custom OOP structure.
I'm not really sure what the actual problem is, but I've reached the
point where this:
class SelectBoxOption extends Tag {
function SelectBoxOption($name, $value, $selected=false) {
parent::Tag("option", $name);
$this->addAttribute("value", $value);
if($selected) {
$this->addAttribute("selected", '', false);
}
if ($name == "") { echo " missing name!<br>\n"; }
// else { print " name $name<br>\n"; }
if ($value == "") { echo " missing value!<br>\n"; }
}
will parse and execute, but:
- the page will contain "missing value!" for each <option> in the
<select> this is generating
- it will *not* contain "missing name!"
- the <option> tags in the final output don't have content or value
(they should have both).
If I uncomment that else, I get:
adding option <name1> with <value1>
name <value1>
Catchable fatal error: Object of class SelectBoxOption could not be
converted to string in
<webroot>/includes/classes/core/display/form/input/SelectBoxOption.php
on line 12
I found the place this object is created, and added some debugging
output before *and* after that call:
echo "adding option ".$row->$nameField." with ".
$row->$valueField."<br>\n";
$this->add(new SelectBoxOption($row->$nameField,
$row->$valueField, $selected));
echo "added option ".$row->$nameField." with ".
$row->$valueField."<br>\n";
which behaves correctly and spits out the name and value (retrieved from
a database - thankfully I haven't had to track *that* down... yet).
Can anyone explain why a string passed by value (apparently) would
suddenly mutate into a SelectBoxOption object? I've confirmed that this
is exactly what happens by adding this:
if (is_a($name,'SelectBoxOption')) {
print "name isn't a SelectBoxOption, silly rabbit!<br>\n";
}
as the very next set of lines after "function SelectBoxOption(....".
I wondered while typing this if $name and $value might have ended up as
special variables somewhere, but renaming them with an opt_ prefix
didn't change anything.
-kgd
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Kris Deugau [mailto:[email protected]]
> Sent: Thursday, December 16, 2010 11:57 AM
> To: [email protected]
> Subject: [PHP] String passed to object constructor turning into an
instance of
> that object?
>
> I'm in the process of migrating customer websites off an old legacy server
> that's pushing EOL, and starting to show hardware failures.
>
> One site is throwing errors on what, so far as I can tell, should be
perfectly
> working code.
>
> The original code works fine on both CentOS 3 (PHP 4.3.2) and CentOS 4
> (4.3.9); the "new" server is still a bit outdated (Debian etch plus some
> backports and updates from lenny; PHP 5.2.0).
>
> The site was designed by staff at a previous hosting company and uses a
> combination of the Fusebox app framework (which seems to work OK, after
> a few relatively minor fixes) and a custom OOP structure.
>
> I'm not really sure what the actual problem is, but I've reached the point
> where this:
>
>
> class SelectBoxOption extends Tag {
> function SelectBoxOption($name, $value, $selected=false) {
> parent::Tag("option", $name);
> $this->addAttribute("value", $value);
> if($selected) {
> $this->addAttribute("selected", '', false);
> }
> if ($name == "") { echo " missing name!<br>\n"; }
> // else { print " name $name<br>\n"; }
> if ($value == "") { echo " missing value!<br>\n"; }
> }
>
>
> will parse and execute, but:
> - the page will contain "missing value!" for each <option> in the
> <select> this is generating
> - it will *not* contain "missing name!"
> - the <option> tags in the final output don't have content or value
> (they should have both).
>
> If I uncomment that else, I get:
>
>
> adding option <name1> with <value1>
> name <value1>
>
> Catchable fatal error: Object of class SelectBoxOption could not be
> converted to string in
> <webroot>/includes/classes/core/display/form/input/SelectBoxOption.php
> on line 12
>
What's the actual line #12 in the file SelectBoxOption.php? The
SelectBoxOption code you presented has 11 lines unless it's a CNP error.
Regards,
Tommy
>
> I found the place this object is created, and added some debugging
> output before *and* after that call:
>
>
> echo "adding option ".$row->$nameField." with ".
> $row->$valueField."<br>\n";
> $this->add(new SelectBoxOption($row->$nameField,
> $row->$valueField, $selected));
> echo "added option ".$row->$nameField." with ".
> $row->$valueField."<br>\n";
>
>
> which behaves correctly and spits out the name and value (retrieved from
> a database - thankfully I haven't had to track *that* down... yet).
>
> Can anyone explain why a string passed by value (apparently) would
> suddenly mutate into a SelectBoxOption object? I've confirmed that this
> is exactly what happens by adding this:
>
>
> if (is_a($name,'SelectBoxOption')) {
> print "name isn't a SelectBoxOption, silly rabbit!<br>\n";
> }
>
>
> as the very next set of lines after "function SelectBoxOption(....".
>
> I wondered while typing this if $name and $value might have ended up as
> special variables somewhere, but renaming them with an opt_ prefix
> didn't change anything.
>
> -kgd
>
--- End Message ---
--- Begin Message ---
Tommy Pham wrote:
class SelectBoxOption extends Tag {
function SelectBoxOption($name, $value, $selected=false) {
parent::Tag("option", $name);
$this->addAttribute("value", $value);
if($selected) {
$this->addAttribute("selected", '', false);
}
if ($name == "") { echo " missing name!<br>\n"; }
// else { print " name $name<br>\n"; }
if ($value == "") { echo " missing value!<br>\n"; }
}
will parse and execute, but:
- the page will contain "missing value!" for each <option> in the
<select> this is generating
- it will *not* contain "missing name!"
- the <option> tags in the final output don't have content or value
(they should have both).
If I uncomment that else, I get:
adding option <name1> with <value1>
name <value1>
Catchable fatal error: Object of class SelectBoxOption could not be
converted to string in
<webroot>/includes/classes/core/display/form/input/SelectBoxOption.php
on line 12
What's the actual line #12 in the file SelectBoxOption.php? The
SelectBoxOption code you presented has 11 lines unless it's a CNP error.
Whups, thought I noted that. I trimmed a couple of blank lines; line
12 in the file is that print in the else.
I found trying to print $name triggers the same error anywhere in that
function, too; as I noted further down it seems the string that's
passed in is getting mutated into an object. (Whose missing toString
function is what led me here - but it works fine in PHP 4.3...)
-kgd
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 2:29 PM, Kris Deugau <[email protected]> wrote:
> Tommy Pham wrote:
>
>> class SelectBoxOption extends Tag {
>>> function SelectBoxOption($name, $value, $selected=false) {
>>> parent::Tag("option", $name);
>>> $this->addAttribute("value", $value);
>>> if($selected) {
>>> $this->addAttribute("selected", '', false);
>>> }
>>> if ($name == "") { echo " missing name!<br>\n"; }
>>> // else { print " name $name<br>\n"; }
>>> if ($value == "") { echo " missing value!<br>\n"; }
>>> }
>>>
>>>
>>> will parse and execute, but:
>>> - the page will contain "missing value!" for each <option> in the
>>> <select> this is generating
>>> - it will *not* contain "missing name!"
>>> - the <option> tags in the final output don't have content or value
>>> (they should have both).
>>>
>>> If I uncomment that else, I get:
>>>
>>>
>>> adding option <name1> with <value1>
>>> name <value1>
>>>
>>> Catchable fatal error: Object of class SelectBoxOption could not be
>>> converted to string in
>>> <webroot>/includes/classes/core/display/form/input/SelectBoxOption.php
>>> on line 12
>>>
>>
> What's the actual line #12 in the file SelectBoxOption.php? The
>> SelectBoxOption code you presented has 11 lines unless it's a CNP error.
>>
>
> Whups, thought I noted that. I trimmed a couple of blank lines; line 12
> in the file is that print in the else.
>
> I found trying to print $name triggers the same error anywhere in that
> function, too; as I noted further down it seems the string that's passed in
> is getting mutated into an object. (Whose missing toString function is what
> led me here - but it works fine in PHP 4.3...)
Why not test for the type of $name at each point of interest in the
SelectBoxOption
constructor? If you're passing a string value to the constructor it almost
has to be getting changed by the Tag constructor, right ?
class SelectBoxOption extends Tag {
function SelectBoxOption($name, $value, $selected=false) {
var_dump(is_string($name));
parent::Tag("option", $name);
var_dump(is_string($name));
..
}
-nathan
--- End Message ---
--- Begin Message ---
Nathan Nobbe wrote:
Why not test for the type of $name at each point of interest in the
SelectBoxOption
constructor? If you're passing a string value to the constructor it almost
has to be getting changed by the Tag constructor, right ?
class SelectBoxOption extends Tag {
function SelectBoxOption($name, $value, $selected=false) {
var_dump(is_string($name));
parent::Tag("option", $name);
var_dump(is_string($name));
Ah, that gives... well, it slightly alters the confusion.
Using var_dump(is_string($name)) gives... two results?
bool(true)
bool(false)
And dumping $name itself gives:
string(8) "Abegweit"
object(SelectBoxOption)#65 (5) { ["attributes"]=> array(1) { [0]=>
object(TagAttribute)#66 (3) { ["name"]=> string(5) "value" ["value"]=>
string(1) "4" ["hasValue"]=> bool(true) } } ["tagContent"]=> string(8)
"Abegweit" ["tag"]=> string(6) "option" ["showEndTag"]=> bool(false)
["children"]=> array(0) { } }
O_o
Just to confirm, I checked a test instance of the site on CentOS 4, with
PHP 4.3, and I get one "bool(true)" for each <option> - not two as is
happening with PHP 5.2.
-kgd
(I haven't worked with PHP for quite a while, and I never really spent a
lot of time getting deep into complex data structures and object
hierarchies like this when I was using it. But this behaviour does NOT
match what I know of passing values and object references around in any
other language.)
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 3:21 PM, Kris Deugau <[email protected]> wrote:
> Nathan Nobbe wrote:
>
>> Why not test for the type of $name at each point of interest in the
>> SelectBoxOption
>> constructor? If you're passing a string value to the constructor it
>> almost
>> has to be getting changed by the Tag constructor, right ?
>>
>> class SelectBoxOption extends Tag {
>> function SelectBoxOption($name, $value, $selected=false) {
>>
>> var_dump(is_string($name));
>>
>> parent::Tag("option", $name);
>>
>> var_dump(is_string($name));
>>
>
> Ah, that gives... well, it slightly alters the confusion.
>
> Using var_dump(is_string($name)) gives... two results?
>
> bool(true)
> bool(false)
>
> And dumping $name itself gives:
>
> string(8) "Abegweit"
> object(SelectBoxOption)#65 (5) { ["attributes"]=> array(1) { [0]=>
> object(TagAttribute)#66 (3) { ["name"]=> string(5) "value" ["value"]=>
> string(1) "4" ["hasValue"]=> bool(true) } } ["tagContent"]=> string(8)
> "Abegweit" ["tag"]=> string(6) "option" ["showEndTag"]=> bool(false)
> ["children"]=> array(0) { } }
>
> O_o
>
> Just to confirm, I checked a test instance of the site on CentOS 4, with
> PHP 4.3, and I get one "bool(true)" for each <option> - not two as is
> happening with PHP 5.2.
>
probly something screwy going on w/ the old style of naming constructors. 2
things,
1. can you post the Tag constructor as it reads now?
2. try modifying Tag & SelectBoxOption to have __construct() instead of
Tag() & SelectBoxOption(), then call parent::__construct() from inside
of SelectBoxOption::__construct(); see if that clears up your problem under
5.2 (read: this will only be a partial solution as it only addresses one
child of Tag).
> -kgd
>
> (I haven't worked with PHP for quite a while, and I never really spent a
> lot of time getting deep into complex data structures and object hierarchies
> like this when I was using it. But this behaviour does NOT match what I
> know of passing values and object references around in any other language.)
>
Probly because the term 'reference' in php means something rather different
than it does in say java for example.
--- End Message ---
--- Begin Message ---
It's acting as if Tag's constructor a) declares $name as a reference using
&$name, and b) is assigning itself ($this) to $name for some (probably bad)
reason. That's the only way I can see that $name inside SelectBoxOption's
constructor could change from a string to an object.
A peek at Tag's constructor could really clear things up.
David
--- End Message ---
--- Begin Message ---
Nathan Nobbe wrote:
probly something screwy going on w/ the old style of naming constructors. 2
things,
1. can you post the Tag constructor as it reads now?
function Tag($tag='', $tagContent='') {
$this->tagContent = $tagContent;
$this->tag = $tag;
$this->showEndTag = false;
$this->attributes = array();
$this->children = array();
}
2. try modifying Tag & SelectBoxOption to have __construct() instead of
Tag() & SelectBoxOption(), then call parent::__construct() from inside
of SelectBoxOption::__construct(); see if that clears up your problem under
5.2 (read: this will only be a partial solution as it only addresses one
child of Tag).
Mmm. I hoped this would help, but all it seems to have done was cascade
errors across the rest of Tag's object children. :( Copying the old
constructor back in resolved that, but I'm not sure whether that
reintroduces the root problem.
Other objects derived from Tag seem to work just fine; I came into this
chunk of the code trying to find out why a SelectBoxOption didn't seem
to have a toString function - and then why trying to access what should
be the value and name the same way as with other objects derived at some
level from Tag blew up instead of working happily.
I'll try converting all of the constructors to your recommendation as
above, but given that the problem is only happening with this one class,
I'm not sure that will do much.
(A "don't-break-crusty-old-code" option for php.ini would be handy...)
The class hierarchy I've dug up so far looks like this (and appears to
have been entirely defined by the original developer):
Object
Fieldset
RadioButtonGroup
Tag
Column
FormObject
FormInput
CheckBox
DateSelector
Editor
FileField
FormButton
HiddenField
PasswordField
RadioButton
SelectBox
PopulatedSelectBox
RecursiveSelectBox
TextArea
TextField
Form
Row
Table
SelectBoxOption
-kgd
--- End Message ---
--- Begin Message ---
On Thu, Dec 16, 2010 at 4:04 PM, Kris Deugau <[email protected]> wrote:
> Nathan Nobbe wrote:
>
>> probly something screwy going on w/ the old style of naming constructors.
>> 2
>> things,
>>
>> 1. can you post the Tag constructor as it reads now?
>>
>
> function Tag($tag='', $tagContent='') {
> $this->tagContent = $tagContent;
> $this->tag = $tag;
> $this->showEndTag = false;
>
> $this->attributes = array();
> $this->children = array();
>
> }
>
seems innocuous ..
>
> 2. try modifying Tag & SelectBoxOption to have __construct() instead of
>> Tag() & SelectBoxOption(), then call parent::__construct() from inside
>> of SelectBoxOption::__construct(); see if that clears up your problem
>> under
>> 5.2 (read: this will only be a partial solution as it only addresses one
>> child of Tag).
>>
>
> Mmm. I hoped this would help, but all it seems to have done was cascade
> errors across the rest of Tag's object children. :(
to be expected, but did it fix the problem w/ SelectBoxOption?
> Copying the old constructor back in resolved that, but I'm not sure whether
> that reintroduces the root problem.
> Other objects derived from Tag seem to work just fine; I came into this
> chunk of the code trying to find out why a SelectBoxOption didn't seem to
> have a toString function - and then why trying to access what should be the
> value and name the same way as with other objects derived at some level from
> Tag blew up instead of working happily.
>
> I'll try converting all of the constructors to your recommendation as
> above, but given that the problem is only happening with this one class, I'm
> not sure that will do much.
>
hopefully that clears it up .. and hopefully you're using version control :D
-nathan
--- End Message ---
--- Begin Message ---
I've never used the old-style constructors, but perhaps the semantics of
"parent::" changed and you need to instead use "$this->" as in
$this->Tag("option", $name);
That's a total guess. I don't have 5.2 handy to try it out, but both work in
5.3 using a simple example. Can you post the constructor of one of the Tag
subclasses that work? Maybe we can find a common denominator.
David
--- End Message ---
