Groups > comp.lang.php > #5244 > unrolled thread

out of sheer curiosity...

Started by	"Leonardo Azpurua" <leonardo@exmvps.org>
First post	2012-03-27 12:31 -0430
Last post	2012-04-12 07:45 -0400
Articles	20 on this page of 96 — 10 participants

Back to article view | Back to comp.lang.php

  out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 12:31 -0430
    Re: out of sheer curiosity... "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-03-27 19:06 +0200
      Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 13:04 -0430
    Re: out of sheer curiosity... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-28 21:12 +0200
      Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-28 20:23 -0430
        Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 10:00 +0200
          Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-29 05:23 -0430
            Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 11:46 +0100
              Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 14:02 +0200
              Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 14:33 +0200
                Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 14:37 +0100
                  Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 15:59 +0200
                    Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 17:58 +0100
                Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 09:39 -0400
                  Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 16:21 +0200
                    Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 18:09 +0100
                      Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:07 +0100
                        Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 23:43 +0200
                        Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-30 04:52 +0100
                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 16:11 -0400
                      Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:01 +0100
                        Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 19:29 -0400
                      Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-08 22:50 +0200
                        Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 17:15 -0400
                          Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 00:39 +0200
                            Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-09 00:59 +0100
                              Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:28 -0400
                            Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:24 -0400
                              Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 11:29 +0200
                                Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 08:27 -0400
                                  Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 15:20 +0200
                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 12:03 -0400
                                      Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 20:04 +0200
                                        Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 14:37 -0400
                                          Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 22:50 +0200
                                            Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:17 -0400
                                              Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 10:05 +0200
                                                Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:28 +0200
                                                  Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 18:54 +0200
                                                    Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:10 +0200
                                                      Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:23 +0200
                                                        Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:17 +0200
                                                      Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:11 -0400
                                                        Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:30 +0200
                                                          Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:43 -0400
                                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:08 -0400
                                                      Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-11 10:40 +0200
                                                Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 07:58 -0400
                                                  Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 16:04 +0100
                                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:10 -0400
                                                      Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:18 +0200
                                                        Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-10 18:20 +0100
                                                          Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:31 +0200
                                                        Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:20 -0400
                                                          Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:57 +0200
                                                            Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:50 -0400
                                                      Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 17:41 +0100
                                                  Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:25 +0200
                                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:16 -0400
                                              Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:44 +0200
                                                Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:04 -0400
                                                  Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:37 +0200
                                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:19 -0400
                                                      Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:44 +0200
                                                        Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:23 -0400
                                        Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 11:50 -0700
                                          Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 23:03 +0200
                                            Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 15:27 -0700
                                              Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:25 -0400
                                                Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:48 +0200
                                                  Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:06 -0400
                                                    Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 07:52 -0430
                                                      Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:20 -0400
                                                        Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 12:03 -0430
                                                          Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:28 -0400
                                                            Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 00:13 +0200
                                                              Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:53 -0400
                                                                Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:17 +0200
                                                                  Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:30 -0400
                                            Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:22 -0400
                                              Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:43 +0200
                                                Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:11 -0400
                                                  Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:15 +0200
                                                    Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:09 +0200
                                                      Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:17 +0200
                                                        Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:25 +0200
                                                          Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:21 +0200
                                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:34 -0400
                                                      Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 01:00 +0200
                                                        Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:54 -0400
                                                          Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:10 +0200
                                                            Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:31 -0400
                                                              Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:40 +0200
                                                                Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:02 -0400
                                                                  Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-12 12:00 +0200
                                                                    Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 07:45 -0400

Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →

#5262

From	Tim Streater <timstreater@greenbee.net>
Date	2012-03-29 22:01 +0100
Message-ID	<timstreater-468BAD.22013529032012@news.individual.net>
In reply to	#5261

In article <jl2fl0$v97$1@dont-email.me>,
 Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 29/3/2012 10:21 AM, Erwin Moller wrote:

> > What are your main objections to the PHP5's OO approach?
> >
> > For myself: I must say I love its simplicity.
> > (Simplicity is a Good Thing in my opinion.)

> Well, to start with, the lack of function overloading.  It is quite a 
> good feature to be able to overload functions - especially constructors. 
>   And because of that, you have to run through all kinds of hoops when 
> doing things like storing an object in the $_SESSION.

[snip other reasons]

You brought any of this up on the PHP mailing lists?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#5265

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-03-29 19:29 -0400
Message-ID	<jl2r83$522$1@dont-email.me>
In reply to	#5262

On 3/29/2012 5:01 PM, Tim Streater wrote:
> In article <jl2fl0$v97$1@dont-email.me>,
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 29/3/2012 10:21 AM, Erwin Moller wrote:
>
>> > What are your main objections to the PHP5's OO approach?
>> >
>> > For myself: I must say I love its simplicity.
>> > (Simplicity is a Good Thing in my opinion.)
>
>> Well, to start with, the lack of function overloading. It is quite a
>> good feature to be able to overload functions - especially
>> constructors. And because of that, you have to run through all kinds
>> of hoops when doing things like storing an object in the $_SESSION.
>
> [snip other reasons]
>
> You brought any of this up on the PHP mailing lists?
>

It's been brought up so many times it isn't even funny, and some of it 
in the bugs list.

I do not have a lot of respect for those in charge of PHP.  Just because 
they can program an interpreter does not mean they can design a 
language.  And PHP is proof of that.


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

[toc] | [prev] | [next] | [standalone]

#5368

From	"M. Strobel" <sorry_no_mail_here@nowhere.dee>
Date	2012-04-08 22:50 +0200
Message-ID	<9uebvuFt0pU1@mid.uni-berlin.de>
In reply to	#5261

Am 29.03.2012 22:11, schrieb Jerry Stuckle:
> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>
>> <snip>
>>
>>>>> Its just another way of doing things and I let my understanding of the
>>>>> problem guide me, not a set of arbitrary rules.
>>>>
>>>> As it should!
>>>>
>>>> But what 'rules' are you referring to?
>>>>
>>>> PHP's OO is pretty straightforward.
>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>
>>>> Creating smart classes is up to the programmer.
>>>> I am not aware of any extra 'rules'.
>>>>
>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>> the web?
>>>> (In which case I tend to agree, because implementing other people's
>>>> solutions can take the fun out of programming. But reading them never
>>>> hurts. And when you agree to a certain approach you can even decide to
>>>> follow it yourself. It is all up to you, the programmer.)
>>>>
>>>
>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>> said in the past.
>>>
>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>> half-assed at best. Truly written by people who have no understanding of
>>> OO. But then that can be said of a lot of PHP.
>>>
>>
>> Jerry,
>>
>> What are your main objections to the PHP5's OO approach?
>>
>> For myself: I must say I love its simplicity.
>> (Simplicity is a Good Thing in my opinion.)
>>
>>
> 
> Well, to start with, the lack of function overloading.  It is quite a good feature to
> be able to overload functions - especially constructors.  And because of that, you
> have to run through all kinds of hoops when doing things like storing an object in
> the $_SESSION.
> 
> Even then it doesn't work.  When you store an object in the $_SESSION, the object's
> destructor is called at the end of the script, but on the next script the constructor
> is never called.  A direct violation of OO principles.

Works fine here. Test script:
#!/usr/local/bin/php
<?php

class C1 {
public $var1 = 'M.';
public $var2 = 'Strobel';
    function __construct() {
        echo "\t--> call ". __METHOD__.PHP_EOL;
    }
    function __destruct() {
       echo "\t--> call ". __METHOD__.PHP_EOL;
    }
    function __sleep() {
       echo "\t--> call ". __METHOD__.PHP_EOL;
       return array('var1','var2');
    }
    function __wakeup() {
       echo "\t--> call ". __METHOD__.PHP_EOL;
    }
} // end class C1

echo "----- creating class\n";
$c = new C1;
echo "----- serializing class\n";
$ser = serialize($c);
echo "----- deserializing class\n";
$cc = unserialize($ser);
echo "----- deleting first class\n";
unset($c);
echo "----- deleting unserialized class\n";
unset($cc);
exit(0);
#-----------------------

Result:
strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
----- creating class
        --> call C1::__construct
----- serializing class
        --> call C1::__sleep
----- deserializing class
        --> call C1::__wakeup
----- deleting first class
        --> call C1::__destruct
----- deleting unserialized class
        --> call C1::__destruct

What exactly did you criticize?

/Str.

[toc] | [prev] | [next] | [standalone]

#5369

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-08 17:15 -0400
Message-ID	<jlsv4m$e1o$1@dont-email.me>
In reply to	#5368

On 4/8/2012 4:50 PM, M. Strobel wrote:
> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>
>>> <snip>
>>>
>>>>>> Its just another way of doing things and I let my understanding of the
>>>>>> problem guide me, not a set of arbitrary rules.
>>>>>
>>>>> As it should!
>>>>>
>>>>> But what 'rules' are you referring to?
>>>>>
>>>>> PHP's OO is pretty straightforward.
>>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>>
>>>>> Creating smart classes is up to the programmer.
>>>>> I am not aware of any extra 'rules'.
>>>>>
>>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>>> the web?
>>>>> (In which case I tend to agree, because implementing other people's
>>>>> solutions can take the fun out of programming. But reading them never
>>>>> hurts. And when you agree to a certain approach you can even decide to
>>>>> follow it yourself. It is all up to you, the programmer.)
>>>>>
>>>>
>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>> said in the past.
>>>>
>>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>> half-assed at best. Truly written by people who have no understanding of
>>>> OO. But then that can be said of a lot of PHP.
>>>>
>>>
>>> Jerry,
>>>
>>> What are your main objections to the PHP5's OO approach?
>>>
>>> For myself: I must say I love its simplicity.
>>> (Simplicity is a Good Thing in my opinion.)
>>>
>>>
>>
>> Well, to start with, the lack of function overloading.  It is quite a good feature to
>> be able to overload functions - especially constructors.  And because of that, you
>> have to run through all kinds of hoops when doing things like storing an object in
>> the $_SESSION.
>>
>> Even then it doesn't work.  When you store an object in the $_SESSION, the object's
>> destructor is called at the end of the script, but on the next script the constructor
>> is never called.  A direct violation of OO principles.
>
> Works fine here. Test script:
> #!/usr/local/bin/php
> <?php
>
> class C1 {
> public $var1 = 'M.';
> public $var2 = 'Strobel';
>      function __construct() {
>          echo "\t-->  call ". __METHOD__.PHP_EOL;
>      }
>      function __destruct() {
>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>      }
>      function __sleep() {
>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>         return array('var1','var2');
>      }
>      function __wakeup() {
>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>      }
> } // end class C1
>
> echo "----- creating class\n";
> $c = new C1;
> echo "----- serializing class\n";
> $ser = serialize($c);
> echo "----- deserializing class\n";
> $cc = unserialize($ser);
> echo "----- deleting first class\n";
> unset($c);
> echo "----- deleting unserialized class\n";
> unset($cc);
> exit(0);
> #-----------------------
>
> Result:
> strobel@s114-intel:~/projekte/PHP>  ./magicmethods.php
> ----- creating class
>          -->  call C1::__construct
> ----- serializing class
>          -->  call C1::__sleep
> ----- deserializing class
>          -->  call C1::__wakeup
> ----- deleting first class
>          -->  call C1::__destruct
> ----- deleting unserialized class
>          -->  call C1::__destruct
>
> What exactly did you criticize?
>
> /Str.

Look at it again.  You have two destructor calls but only one 
constructor call.  A direct violation of OO principles.

And BTW - I said nothing about serializing.

You really do need to learn to read.

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

[toc] | [prev] | [next] | [standalone]

#5373

From	"M. Strobel" <sorry_no_mail_here@nowhere.dee>
Date	2012-04-09 00:39 +0200
Message-ID	<9ueidtFagfU1@mid.uni-berlin.de>
In reply to	#5369

Am 08.04.2012 23:15, schrieb Jerry Stuckle:
> On 4/8/2012 4:50 PM, M. Strobel wrote:
>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>>
>>>> <snip>
>>>>
>>>>>>> Its just another way of doing things and I let my understanding of the
>>>>>>> problem guide me, not a set of arbitrary rules.
>>>>>>
>>>>>> As it should!
>>>>>>
>>>>>> But what 'rules' are you referring to?
>>>>>>
>>>>>> PHP's OO is pretty straightforward.
>>>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>>>
>>>>>> Creating smart classes is up to the programmer.
>>>>>> I am not aware of any extra 'rules'.
>>>>>>
>>>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>>>> the web?
>>>>>> (In which case I tend to agree, because implementing other people's
>>>>>> solutions can take the fun out of programming. But reading them never
>>>>>> hurts. And when you agree to a certain approach you can even decide to
>>>>>> follow it yourself. It is all up to you, the programmer.)
>>>>>>
>>>>>
>>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>>> said in the past.
>>>>>
>>>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>>> half-assed at best. Truly written by people who have no understanding of
>>>>> OO. But then that can be said of a lot of PHP.
>>>>>
>>>>
>>>> Jerry,
>>>>
>>>> What are your main objections to the PHP5's OO approach?
>>>>
>>>> For myself: I must say I love its simplicity.
>>>> (Simplicity is a Good Thing in my opinion.)
>>>>
>>>>
>>>
>>> Well, to start with, the lack of function overloading.  It is quite a good feature to
>>> be able to overload functions - especially constructors.  And because of that, you
>>> have to run through all kinds of hoops when doing things like storing an object in
>>> the $_SESSION.
>>>
>>> Even then it doesn't work.  When you store an object in the $_SESSION, the object's
>>> destructor is called at the end of the script, but on the next script the constructor
>>> is never called.  A direct violation of OO principles.
>>
>> Works fine here. Test script:
>> #!/usr/local/bin/php
>> <?php
>>
>> class C1 {
>> public $var1 = 'M.';
>> public $var2 = 'Strobel';
>>      function __construct() {
>>          echo "\t-->  call ". __METHOD__.PHP_EOL;
>>      }
>>      function __destruct() {
>>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>>      }
>>      function __sleep() {
>>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>>         return array('var1','var2');
>>      }
>>      function __wakeup() {
>>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>>      }
>> } // end class C1
>>
>> echo "----- creating class\n";
>> $c = new C1;
>> echo "----- serializing class\n";
>> $ser = serialize($c);
>> echo "----- deserializing class\n";
>> $cc = unserialize($ser);
>> echo "----- deleting first class\n";
>> unset($c);
>> echo "----- deleting unserialized class\n";
>> unset($cc);
>> exit(0);
>> #-----------------------
>>
>> Result:
>> strobel@s114-intel:~/projekte/PHP>  ./magicmethods.php
>> ----- creating class
>>          -->  call C1::__construct
>> ----- serializing class
>>          -->  call C1::__sleep
>> ----- deserializing class
>>          -->  call C1::__wakeup
>> ----- deleting first class
>>          -->  call C1::__destruct
>> ----- deleting unserialized class
>>          -->  call C1::__destruct
>>
>> What exactly did you criticize?
>>
>> /Str.
> 
> Look at it again.  You have two destructor calls but only one constructor call.  A
> direct violation of OO principles.
> 
> And BTW - I said nothing about serializing.
> 
> You really do need to learn to read.
> 

No evasions, get to the point. I have one explicit constructor, and one wakeup which
is a constructor.

What did you talk about if not about serializing?

/Str.

[toc] | [prev] | [next] | [standalone]

#5374

From	The Natural Philosopher <tnp@invalid.invalid>
Date	2012-04-09 00:59 +0100
Message-ID	<jlt8o6$erh$2@news.albasani.net>
In reply to	#5373

M. Strobel wrote:
> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>>> <snip>
>>>>>
>>>>>>>> Its just another way of doing things and I let my understanding of the
>>>>>>>> problem guide me, not a set of arbitrary rules.
>>>>>>> As it should!
>>>>>>>
>>>>>>> But what 'rules' are you referring to?
>>>>>>>
>>>>>>> PHP's OO is pretty straightforward.
>>>>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>>>>
>>>>>>> Creating smart classes is up to the programmer.
>>>>>>> I am not aware of any extra 'rules'.
>>>>>>>
>>>>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>>>>> the web?
>>>>>>> (In which case I tend to agree, because implementing other people's
>>>>>>> solutions can take the fun out of programming. But reading them never
>>>>>>> hurts. And when you agree to a certain approach you can even decide to
>>>>>>> follow it yourself. It is all up to you, the programmer.)
>>>>>>>
>>>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>>>> said in the past.
>>>>>>
>>>>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>>>> half-assed at best. Truly written by people who have no understanding of
>>>>>> OO. But then that can be said of a lot of PHP.
>>>>>>
>>>>> Jerry,
>>>>>
>>>>> What are your main objections to the PHP5's OO approach?
>>>>>
>>>>> For myself: I must say I love its simplicity.
>>>>> (Simplicity is a Good Thing in my opinion.)
>>>>>
>>>>>
>>>> Well, to start with, the lack of function overloading.  It is quite a good feature to
>>>> be able to overload functions - especially constructors.  And because of that, you
>>>> have to run through all kinds of hoops when doing things like storing an object in
>>>> the $_SESSION.
>>>>
>>>> Even then it doesn't work.  When you store an object in the $_SESSION, the object's
>>>> destructor is called at the end of the script, but on the next script the constructor
>>>> is never called.  A direct violation of OO principles.
>>> Works fine here. Test script:
>>> #!/usr/local/bin/php
>>> <?php
>>>
>>> class C1 {
>>> public $var1 = 'M.';
>>> public $var2 = 'Strobel';
>>>      function __construct() {
>>>          echo "\t-->  call ". __METHOD__.PHP_EOL;
>>>      }
>>>      function __destruct() {
>>>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>>>      }
>>>      function __sleep() {
>>>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>>>         return array('var1','var2');
>>>      }
>>>      function __wakeup() {
>>>         echo "\t-->  call ". __METHOD__.PHP_EOL;
>>>      }
>>> } // end class C1
>>>
>>> echo "----- creating class\n";
>>> $c = new C1;
>>> echo "----- serializing class\n";
>>> $ser = serialize($c);
>>> echo "----- deserializing class\n";
>>> $cc = unserialize($ser);
>>> echo "----- deleting first class\n";
>>> unset($c);
>>> echo "----- deleting unserialized class\n";
>>> unset($cc);
>>> exit(0);
>>> #-----------------------
>>>
>>> Result:
>>> strobel@s114-intel:~/projekte/PHP>  ./magicmethods.php
>>> ----- creating class
>>>          -->  call C1::__construct
>>> ----- serializing class
>>>          -->  call C1::__sleep
>>> ----- deserializing class
>>>          -->  call C1::__wakeup
>>> ----- deleting first class
>>>          -->  call C1::__destruct
>>> ----- deleting unserialized class
>>>          -->  call C1::__destruct
>>>
>>> What exactly did you criticize?
>>>
>>> /Str.
>> Look at it again.  You have two destructor calls but only one constructor call.  A
>> direct violation of OO principles.
>>
>> And BTW - I said nothing about serializing.
>>
>> You really do need to learn to read.
>>
> 
> No evasions, get to the point. I have one explicit constructor, and one wakeup which
> is a constructor.
> 
> What did you talk about if not about serializing?
> 
> /Str.


c'mon. Jerry just cut and pasted something he read somewhere.

Its not as if he understood what he was posting. Go easy on the poor old 
chap.


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#5376

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-08 20:28 -0400
Message-ID	<jltaep$9j3$1@dont-email.me>
In reply to	#5374

On 4/8/2012 7:59 PM, The Natural Philosopher wrote:
> M. Strobel wrote:
>> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>>>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>>>> <snip>
>>>>>>
>>>>>>>>> Its just another way of doing things and I let my understanding
>>>>>>>>> of the
>>>>>>>>> problem guide me, not a set of arbitrary rules.
>>>>>>>> As it should!
>>>>>>>>
>>>>>>>> But what 'rules' are you referring to?
>>>>>>>>
>>>>>>>> PHP's OO is pretty straightforward.
>>>>>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>>>>>
>>>>>>>> Creating smart classes is up to the programmer.
>>>>>>>> I am not aware of any extra 'rules'.
>>>>>>>>
>>>>>>>> Are you maybe referring to all kinds of design patterns
>>>>>>>> scattered around
>>>>>>>> the web?
>>>>>>>> (In which case I tend to agree, because implementing other people's
>>>>>>>> solutions can take the fun out of programming. But reading them
>>>>>>>> never
>>>>>>>> hurts. And when you agree to a certain approach you can even
>>>>>>>> decide to
>>>>>>>> follow it yourself. It is all up to you, the programmer.)
>>>>>>>>
>>>>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his
>>>>>>> mind.
>>>>>>> He doesn't even like having to follow PHP syntax rules - as he
>>>>>>> has also
>>>>>>> said in the past.
>>>>>>>
>>>>>>> But I disagree that PHP 5's implementation of OO is decent. I
>>>>>>> think it's
>>>>>>> half-assed at best. Truly written by people who have no
>>>>>>> understanding of
>>>>>>> OO. But then that can be said of a lot of PHP.
>>>>>>>
>>>>>> Jerry,
>>>>>>
>>>>>> What are your main objections to the PHP5's OO approach?
>>>>>>
>>>>>> For myself: I must say I love its simplicity.
>>>>>> (Simplicity is a Good Thing in my opinion.)
>>>>>>
>>>>>>
>>>>> Well, to start with, the lack of function overloading. It is quite
>>>>> a good feature to
>>>>> be able to overload functions - especially constructors. And
>>>>> because of that, you
>>>>> have to run through all kinds of hoops when doing things like
>>>>> storing an object in
>>>>> the $_SESSION.
>>>>>
>>>>> Even then it doesn't work. When you store an object in the
>>>>> $_SESSION, the object's
>>>>> destructor is called at the end of the script, but on the next
>>>>> script the constructor
>>>>> is never called. A direct violation of OO principles.
>>>> Works fine here. Test script:
>>>> #!/usr/local/bin/php
>>>> <?php
>>>>
>>>> class C1 {
>>>> public $var1 = 'M.';
>>>> public $var2 = 'Strobel';
>>>> function __construct() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> function __destruct() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> function __sleep() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> return array('var1','var2');
>>>> }
>>>> function __wakeup() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> } // end class C1
>>>>
>>>> echo "----- creating class\n";
>>>> $c = new C1;
>>>> echo "----- serializing class\n";
>>>> $ser = serialize($c);
>>>> echo "----- deserializing class\n";
>>>> $cc = unserialize($ser);
>>>> echo "----- deleting first class\n";
>>>> unset($c);
>>>> echo "----- deleting unserialized class\n";
>>>> unset($cc);
>>>> exit(0);
>>>> #-----------------------
>>>>
>>>> Result:
>>>> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
>>>> ----- creating class
>>>> --> call C1::__construct
>>>> ----- serializing class
>>>> --> call C1::__sleep
>>>> ----- deserializing class
>>>> --> call C1::__wakeup
>>>> ----- deleting first class
>>>> --> call C1::__destruct
>>>> ----- deleting unserialized class
>>>> --> call C1::__destruct
>>>>
>>>> What exactly did you criticize?
>>>>
>>>> /Str.
>>> Look at it again. You have two destructor calls but only one
>>> constructor call. A
>>> direct violation of OO principles.
>>>
>>> And BTW - I said nothing about serializing.
>>>
>>> You really do need to learn to read.
>>>
>>
>> No evasions, get to the point. I have one explicit constructor, and
>> one wakeup which
>> is a constructor.
>>
>> What did you talk about if not about serializing?
>>
>> /Str.
>
>
> c'mon. Jerry just cut and pasted something he read somewhere.
>
> Its not as if he understood what he was posting. Go easy on the poor old
> chap.
>
>

Ah, the biggest troll on Usenet once again shows just how stoopid he is. 
  He refuses to use his real name because he doesn't want everyone to 
know he's neither a programmer or the electrical engineer he claims to 
be.  He's made that all too obvious so many times.

No, he's just a ditch digger who got fired because he couldn't figure 
out which end of the shovel to use.

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

[toc] | [prev] | [next] | [standalone]

#5375

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-08 20:24 -0400
Message-ID	<jlta8n$8pi$1@dont-email.me>
In reply to	#5373

On 4/8/2012 6:39 PM, M. Strobel wrote:
> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>>> Its just another way of doing things and I let my understanding of the
>>>>>>>> problem guide me, not a set of arbitrary rules.
>>>>>>>
>>>>>>> As it should!
>>>>>>>
>>>>>>> But what 'rules' are you referring to?
>>>>>>>
>>>>>>> PHP's OO is pretty straightforward.
>>>>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>>>>
>>>>>>> Creating smart classes is up to the programmer.
>>>>>>> I am not aware of any extra 'rules'.
>>>>>>>
>>>>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>>>>> the web?
>>>>>>> (In which case I tend to agree, because implementing other people's
>>>>>>> solutions can take the fun out of programming. But reading them never
>>>>>>> hurts. And when you agree to a certain approach you can even decide to
>>>>>>> follow it yourself. It is all up to you, the programmer.)
>>>>>>>
>>>>>>
>>>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>>>> said in the past.
>>>>>>
>>>>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>>>> half-assed at best. Truly written by people who have no understanding of
>>>>>> OO. But then that can be said of a lot of PHP.
>>>>>>
>>>>>
>>>>> Jerry,
>>>>>
>>>>> What are your main objections to the PHP5's OO approach?
>>>>>
>>>>> For myself: I must say I love its simplicity.
>>>>> (Simplicity is a Good Thing in my opinion.)
>>>>>
>>>>>
>>>>
>>>> Well, to start with, the lack of function overloading.  It is quite a good feature to
>>>> be able to overload functions - especially constructors.  And because of that, you
>>>> have to run through all kinds of hoops when doing things like storing an object in
>>>> the $_SESSION.
>>>>
>>>> Even then it doesn't work.  When you store an object in the $_SESSION, the object's
>>>> destructor is called at the end of the script, but on the next script the constructor
>>>> is never called.  A direct violation of OO principles.
>>>
>>> Works fine here. Test script:
>>> #!/usr/local/bin/php
>>> <?php
>>>
>>> class C1 {
>>> public $var1 = 'M.';
>>> public $var2 = 'Strobel';
>>>       function __construct() {
>>>           echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>       }
>>>       function __destruct() {
>>>          echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>       }
>>>       function __sleep() {
>>>          echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>          return array('var1','var2');
>>>       }
>>>       function __wakeup() {
>>>          echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>       }
>>> } // end class C1
>>>
>>> echo "----- creating class\n";
>>> $c = new C1;
>>> echo "----- serializing class\n";
>>> $ser = serialize($c);
>>> echo "----- deserializing class\n";
>>> $cc = unserialize($ser);
>>> echo "----- deleting first class\n";
>>> unset($c);
>>> echo "----- deleting unserialized class\n";
>>> unset($cc);
>>> exit(0);
>>> #-----------------------
>>>
>>> Result:
>>> strobel@s114-intel:~/projekte/PHP>   ./magicmethods.php
>>> ----- creating class
>>>           -->   call C1::__construct
>>> ----- serializing class
>>>           -->   call C1::__sleep
>>> ----- deserializing class
>>>           -->   call C1::__wakeup
>>> ----- deleting first class
>>>           -->   call C1::__destruct
>>> ----- deleting unserialized class
>>>           -->   call C1::__destruct
>>>
>>> What exactly did you criticize?
>>>
>>> /Str.
>>
>> Look at it again.  You have two destructor calls but only one constructor call.  A
>> direct violation of OO principles.
>>
>> And BTW - I said nothing about serializing.
>>
>> You really do need to learn to read.
>>
>
> No evasions, get to the point. I have one explicit constructor, and one wakeup which
> is a constructor.
>
> What did you talk about if not about serializing?
>
> /Str.

I know a one-to-one correspondence is very difficult for someone of your 
(lack of) intellect to understand, but I'll try again anyway.

You have these calls:
  -->   call C1::__construct

That's ONE call to a constructor.


  -->   call C1::__destruct
  -->   call C1::__destruct

That's TWO calls to destructors.  IOW, an object was constructed without 
calling a constructor.  This is a direct violation of OO principals (all 
objects must have exactly one constructor call and one destructor call).

And ONE does not equal TWO.  wakeup() is not a constructor, any more 
than sleep() is a destructor (and if sleep() were a destructor, then you 
would see a call to sleep() and a call to the destructor).

And I was referring to storing in a session, not serializing the data, i.e.

$_SESSION['stupid'] = $idiot;


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

[toc] | [prev] | [next] | [standalone]

#5378

From	"M. Strobel" <sorry_no_mail_here@nowhere.dee>
Date	2012-04-09 11:29 +0200
Message-ID	<9ufofaFvj5U1@mid.uni-berlin.de>
In reply to	#5375

Am 09.04.2012 02:24, schrieb Jerry Stuckle:
> On 4/8/2012 6:39 PM, M. Strobel wrote:
>> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>>>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>>>> Its just another way of doing things and I let my understanding of the
>>>>>>>>> problem guide me, not a set of arbitrary rules.
>>>>>>>>
>>>>>>>> As it should!
>>>>>>>>
>>>>>>>> But what 'rules' are you referring to?
>>>>>>>>
>>>>>>>> PHP's OO is pretty straightforward.
>>>>>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>>>>>
>>>>>>>> Creating smart classes is up to the programmer.
>>>>>>>> I am not aware of any extra 'rules'.
>>>>>>>>
>>>>>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>>>>>> the web?
>>>>>>>> (In which case I tend to agree, because implementing other people's
>>>>>>>> solutions can take the fun out of programming. But reading them never
>>>>>>>> hurts. And when you agree to a certain approach you can even decide to
>>>>>>>> follow it yourself. It is all up to you, the programmer.)
>>>>>>>>
>>>>>>>
>>>>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>>>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>>>>> said in the past.
>>>>>>>
>>>>>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>>>>> half-assed at best. Truly written by people who have no understanding of
>>>>>>> OO. But then that can be said of a lot of PHP.
>>>>>>>
>>>>>>
>>>>>> Jerry,
>>>>>>
>>>>>> What are your main objections to the PHP5's OO approach?
>>>>>>
>>>>>> For myself: I must say I love its simplicity.
>>>>>> (Simplicity is a Good Thing in my opinion.)
>>>>>>
>>>>>>
>>>>>
>>>>> Well, to start with, the lack of function overloading.  It is quite a good
>>>>> feature to
>>>>> be able to overload functions - especially constructors.  And because of that, you
>>>>> have to run through all kinds of hoops when doing things like storing an object in
>>>>> the $_SESSION.
>>>>>
>>>>> Even then it doesn't work.  When you store an object in the $_SESSION, the object's
>>>>> destructor is called at the end of the script, but on the next script the
>>>>> constructor
>>>>> is never called.  A direct violation of OO principles.
>>>>
>>>> Works fine here. Test script:
>>>> #!/usr/local/bin/php
>>>> <?php
>>>>
>>>> class C1 {
>>>> public $var1 = 'M.';
>>>> public $var2 = 'Strobel';
>>>>       function __construct() {
>>>>           echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>>       }
>>>>       function __destruct() {
>>>>          echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>>       }
>>>>       function __sleep() {
>>>>          echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>>          return array('var1','var2');
>>>>       }
>>>>       function __wakeup() {
>>>>          echo "\t-->   call ". __METHOD__.PHP_EOL;
>>>>       }
>>>> } // end class C1
>>>>
>>>> echo "----- creating class\n";
>>>> $c = new C1;
>>>> echo "----- serializing class\n";
>>>> $ser = serialize($c);
>>>> echo "----- deserializing class\n";
>>>> $cc = unserialize($ser);
>>>> echo "----- deleting first class\n";
>>>> unset($c);
>>>> echo "----- deleting unserialized class\n";
>>>> unset($cc);
>>>> exit(0);
>>>> #-----------------------
>>>>
>>>> Result:
>>>> strobel@s114-intel:~/projekte/PHP>   ./magicmethods.php
>>>> ----- creating class
>>>>           -->   call C1::__construct
>>>> ----- serializing class
>>>>           -->   call C1::__sleep
>>>> ----- deserializing class
>>>>           -->   call C1::__wakeup
>>>> ----- deleting first class
>>>>           -->   call C1::__destruct
>>>> ----- deleting unserialized class
>>>>           -->   call C1::__destruct
>>>>
>>>> What exactly did you criticize?
>>>>
>>>> /Str.
>>>
>>> Look at it again.  You have two destructor calls but only one constructor call.  A
>>> direct violation of OO principles.
>>>
>>> And BTW - I said nothing about serializing.
>>>
>>> You really do need to learn to read.
>>>
>>
>> No evasions, get to the point. I have one explicit constructor, and one wakeup which
>> is a constructor.
>>
>> What did you talk about if not about serializing?
>>
>> /Str.
> 
> I know a one-to-one correspondence is very difficult for someone of your (lack of)
> intellect to understand, but I'll try again anyway.

This is evasion, or your troll rite.

> You have these calls:
>  -->   call C1::__construct
> 
> That's ONE call to a constructor.
> 
> 
>  -->   call C1::__destruct
>  -->   call C1::__destruct
> 
> That's TWO calls to destructors.  IOW, an object was constructed without calling a
> constructor.  This is a direct violation of OO principals (all objects must have
> exactly one constructor call and one destructor call).
> 
> And ONE does not equal TWO.  wakeup() is not a constructor, any more than sleep() is
> a destructor (and if sleep() were a destructor, then you would see a call to sleep()
> and a call to the destructor).

You should admit that serialize() is a special function that creates a frozen
portable copy of an object. The object loses it's identity in the process, but keeps
it's data. The calls to sleep() and wakeup() are okay.

> And I was referring to storing in a session, not serializing the data, i.e.
> 
> $_SESSION['stupid'] = $idiot;

You could probably not work in a team, because you can't talk/write. You could
certainly not work as a teacher.

This is very interesting, and I never ran into this in my 20000+ lines of code
(current project), because I have a feeling of what makes sense. I always serialize
my objects myself.

The handling of objects in session variables seems broke. This is IMO no defect in
the object model, but in the session code.

Here is the test code, see yourself:

<head>
<title>object activity in session</title>
<meta http-equiv="content-type"
		content="text/html;charset=utf-8" />
</head>
<body>
<h2>test script, see source code</h2>
<pre>
<?php
session_start();
if (!isset($_SESSION['cnt'])) $_SESSION['cnt']=1;
class C1 {
  public $var1 = 'M. ';
  public $var2 = 'Strobel';
  function __construct() {
	echo "\t--> call ". __METHOD__.PHP_EOL;
  }
  function __destruct() {
     echo "\t--> call ". __METHOD__.PHP_EOL;
  }
  function __sleep() {
     echo "\t--> call ". __METHOD__.PHP_EOL;
     return array('var1','var2');
  }
  function __wakeup() {
     echo "\t--> call ". __METHOD__.PHP_EOL;
  }
  function greet() { echo 'Hi, I am ',$this->var1, $this->var2, "\n"; }
} // end class C1

echo "This is call number ", $_SESSION['cnt'], "\n";

switch ($_SESSION['cnt']) {
	case 1:
		echo "creating object directly in session:\n";
		$_SESSION['c1'] = new C1;
		break;
	case 2:
		echo "Trying to access object in session:\n";
		$_SESSION['c1']->greet();
		break;
	case 3:
		echo "clearing session to start over, return code: ", session_destroy(), "\n";
		break;
	default:
		echo "\nThis should not happen.\n";
}
$_SESSION['cnt']++;
?>
</pre></body></html>


/Str.

[toc] | [prev] | [next] | [standalone]

#5379

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-09 08:27 -0400
Message-ID	<jlukj7$t9t$1@dont-email.me>
In reply to	#5378

On 4/9/2012 5:29 AM, M. Strobel wrote:
>
> You should admit that serialize() is a special function that creates a frozen
> portable copy of an object. The object loses it's identity in the process, but keeps
> it's data. The calls to sleep() and wakeup() are okay.
>

It doesn't make any difference what serialize is.  OO requires exactly 
one constructor and one destructor call for every object.  Other 
languages such as C++, SmallTalk and Java handle it fine.

sleep() and wakeup() are not constructors or destructors, and have a 
different purpose.

>> And I was referring to storing in a session, not serializing the data, i.e.
>>
>> $_SESSION['stupid'] = $idiot;
>
> You could probably not work in a team, because you can't talk/write. You could
> certainly not work as a teacher.

I've been working in team environments for over 40 years.  I have been 
managing multi-programmer projects for over 25 years.  And I have been 
teaching for corporations (mostly Fortune 500) for over 20 years - 
mainly C, C++, Java and OOAD (although some others also).

But then my students are intelligent.  You wouldn't last a month there.

>
> This is very interesting, and I never ran into this in my 20000+ lines of code
> (current project), because I have a feeling of what makes sense. I always serialize
> my objects myself.
>

Shows how stoopid you really are.  Glad you aren't on one of my projects 
- you wouldn't last long (see above).

> The handling of objects in session variables seems broke. This is IMO no defect in
> the object model, but in the session code.
>

It is a flat out conflict in OO requirements.  It has nothing to do with 
sessions.

> Here is the test code, see yourself:
>

<snip>

Who gives a crap?

The bottom line is that PHP violates OO principles.  No other language 
does so.  But then I'm sure you don't have any experience with other 
languages.

> /Str.

You really are showing how ignorant of basic OO principles you are.

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

[toc] | [prev] | [next] | [standalone]

#5380

From	Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de>
Date	2012-04-09 15:20 +0200
Message-ID	<jlunmd$qp5$1@news.albasani.net>
In reply to	#5379

Jerry Stuckle schrieb:

> It doesn't make any difference what serialize is.  OO requires exactly 
> one constructor and one destructor call for every object.

Says who? What does object orientation have to do with constructors and 
destructors? They're not required.

A constructor is called when a new object is constructed. A serialized 
object has already been constructed so there's no point in calling its 
constructor again when it is unserialized. In fact, the process of 
serializing/unserializing creates a copy of the original object. (The 
same holds for clone'd objects, by the way).

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#5381

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-09 12:03 -0400
Message-ID	<jlv19f$9ts$1@dont-email.me>
In reply to	#5380

On 4/9/2012 9:20 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> It doesn't make any difference what serialize is. OO requires exactly
>> one constructor and one destructor call for every object.
>
> Says who? What does object orientation have to do with constructors and
> destructors? They're not required.
>

Check any of the recognized OO experts - Booch and Yourdon, for 
instance.  Constructors are used to build objects, and destructors are 
used to clean up objects.  They have EVERYTHING to do with object 
orientation!

And this is true of ALL true OO languages - such as C++, Java and 
Smalltalk.

> A constructor is called when a new object is constructed. A serialized
> object has already been constructed so there's no point in calling its
> constructor again when it is unserialized. In fact, the process of
> serializing/unserializing creates a copy of the original object. (The
> same holds for clone'd objects, by the way).
>
> Greetings,
> Thomas
>

No, a serialized object is NOT necessarily constructed.  It may have, 
for instance, references to external resources which are no longer 
available, such as a database connection.  When this is the case, the 
object is no longer valid - because the external resource is no longer 
available.

One of the basic tenets of OO is that an object is responsible for its 
own validity.  An object must always be valid (or, if it is not valid 
for some reason, not allow operations on it which depend on it being valid).

The __clone() method is a form of a constructor.  But wakeup() isn't.

And if you argue that wakeup() is a form of a constructor, then you have 
to argue that sleep() is a form of a destructor - in which case it would 
be invalid to call the destructor after calling sleep().

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

[toc] | [prev] | [next] | [standalone]

#5382

From	Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de>
Date	2012-04-09 20:04 +0200
Message-ID	<jlv8cg$2j7$1@news.albasani.net>
In reply to	#5381

Jerry Stuckle schrieb:

> The __clone() method is a form of a constructor.  But wakeup() isn't.

Neither is. Cloning simply copies a previously constructed object while 
__wakeup() changes the state of a previously constructed object.

> And if you argue that wakeup() is a form of a constructor,

I don't and never did.

> then you have 
> to argue that sleep() is a form of a destructor - in which case it would 
> be invalid to call the destructor after calling sleep().

Serialization creates a kind of "frozen" copy of an object. The original 
object continues to exist and its destructor is called as expected. 
Later, the "frozen" copy is "warmed up" and can pretend to be the 
original object, but it is not the same object. The __sleep() and 
__wakeup() methods simply assist with the freezing and warming up and 
have nothing to do with the copying.

To sum it up: A new object can be created by either constructing it 
(which calls __construct()) or by copying an existing object (via clone 
or via serialization) and this happens without calling __construct() on 
the copy since the object is already constructed. And this explains why 
there may be more __destruct() calls than __construct() calls in a script.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#5383

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-09 14:37 -0400
Message-ID	<jlva9f$22r$1@dont-email.me>
In reply to	#5382

On 4/9/2012 2:04 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> The __clone() method is a form of a constructor. But wakeup() isn't.
>
> Neither is. Cloning simply copies a previously constructed object while
> __wakeup() changes the state of a previously constructed object.
>

Yes, __clone() is a form of a constructor.  It creates a new object from 
an existing object of the same type.  In C++ this would be known as the 
copy constructor, for instance.  In Java it is the clone() method.  Both 
are considered constructors.

Also, when the object is serialized, it no longer is an object.  It has 
state but no behavior - the data are there but not the methods.

So when it is deserialized, a new object is created and by definition a 
constructor must be called.

>> And if you argue that wakeup() is a form of a constructor,
>
> I don't and never did.
>
>> then you have to argue that sleep() is a form of a destructor - in
>> which case it would be invalid to call the destructor after calling
>> sleep().
>
> Serialization creates a kind of "frozen" copy of an object. The original
> object continues to exist and its destructor is called as expected.
> Later, the "frozen" copy is "warmed up" and can pretend to be the
> original object, but it is not the same object. The __sleep() and
> __wakeup() methods simply assist with the freezing and warming up and
> have nothing to do with the copying.
>

No, all serialization does is save the contents of the object.  It is no 
longer an object.  The call to the original object's destructor is 
correct.  And, as you mentioned, when it is deserialized, it is no 
longer the same object - it is a new one, so a constructor must be called.

> To sum it up: A new object can be created by either constructing it
> (which calls __construct()) or by copying an existing object (via clone
> or via serialization) and this happens without calling __construct() on
> the copy since the object is already constructed. And this explains why
> there may be more __destruct() calls than __construct() calls in a script.
>
> Greetings,
> Thomas
>

In object oriented programming, a new object can ONLY be created by 
calling a constructor.  As noted above, different languages have 
different terms for them.  But a constructor MUST be called according to 
OO principles.

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

[toc] | [prev] | [next] | [standalone]

#5387

From	Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de>
Date	2012-04-09 22:50 +0200
Message-ID	<jlvi3a$mpa$1@news.albasani.net>
In reply to	#5383

Jerry Stuckle schrieb:

> In object oriented programming, a new object can ONLY be created by 
> calling a constructor.  As noted above, different languages have 
> different terms for them.  But a constructor MUST be called according to 
> OO principles.

Just to avoid confusion: When a new object is created, PHP must do some 
work under the hood like allocating memory etc. and this of course is 
"construction" work which is always done and in that sense a constructor 
is indeed always called.

But after that, there is (or is not) the call to __construct(). And now 
that I think of it, the name __construct() is actually not quite 
correct, since the actual construction of the object is already done at 
that point. What __construct() really does is perform some 
initialization (in Python, the corresponding method is indeed called 
__init__()).

And this initialization is not needed (or might even prove harmful) when 
the object is copied rather than created from scratch, because in that 
case the initialization was already done on the original object and the 
copy was thus created from an already initialized object and it will 
"inherit" the initialized state. Instead, there are __clone() and 
__wakeup() which replace __construct() and can do different 
initialization tasks depending on how the object was created.

Therefore I must correct my earlier remark about neither __clone() nor 
__wakeup() being constructors: __construct(), __clone() and __wakeup() 
are all "of the same kind" -- performing initialization of an object 
depending on how it was created.

On the other hand, __sleep() is not a destructor, because nothing is 
destroyed when it is called. Note that __sleep() is supposed to return 
an array, contrary to __destruct(). So, while the names __sleep() and 
__wakeup() suggest a correspondence like __destruct() and __construct(), 
this is not the case, since __sleep() is called on the original object, 
while __wakeup() is called on the resurrected copy, so they're not 
called on the same object.

Anyway, I must thank you for making me think more thoroughly about this.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#5393

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2012-04-09 20:17 -0400
Message-ID	<jlvu7q$peh$1@dont-email.me>
In reply to	#5387

On 4/9/2012 4:50 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> In object oriented programming, a new object can ONLY be created by
>> calling a constructor. As noted above, different languages have
>> different terms for them. But a constructor MUST be called according
>> to OO principles.
>
> Just to avoid confusion: When a new object is created, PHP must do some
> work under the hood like allocating memory etc. and this of course is
> "construction" work which is always done and in that sense a constructor
> is indeed always called.
>

No, memory allocation is NOT the same as a constructor.  Memory 
allocation makes space for the object.  The constructor initializes it.

> But after that, there is (or is not) the call to __construct(). And now
> that I think of it, the name __construct() is actually not quite
> correct, since the actual construction of the object is already done at
> that point. What __construct() really does is perform some
> initialization (in Python, the corresponding method is indeed called
> __init__()).
>

In OO terminology, the correct term is "constructor".  I'm not familiar 
with Python, so I can't say what Python calls it.  But the name is not 
as important as the job.

> And this initialization is not needed (or might even prove harmful) when
> the object is copied rather than created from scratch, because in that
> case the initialization was already done on the original object and the
> copy was thus created from an already initialized object and it will
> "inherit" the initialized state. Instead, there are __clone() and
> __wakeup() which replace __construct() and can do different
> initialization tasks depending on how the object was created.
>

Initialization is NEVER harmful if it is done properly.  That's the 
whole purpose of initialization!.  wakeup() is NOT a constructor - any 
more than sleep() is a destructor.

> Therefore I must correct my earlier remark about neither __clone() nor
> __wakeup() being constructors: __construct(), __clone() and __wakeup()
> are all "of the same kind" -- performing initialization of an object
> depending on how it was created.
>

wakeup() is not a constructor.  If you consider it a constructor, then 
you must also consider sleep() to be a destructor - in which case it 
would be illegal to call the destructor after calling sleep().

> On the other hand, __sleep() is not a destructor, because nothing is
> destroyed when it is called. Note that __sleep() is supposed to return
> an array, contrary to __destruct(). So, while the names __sleep() and
> __wakeup() suggest a correspondence like __destruct() and __construct(),
> this is not the case, since __sleep() is called on the original object,
> while __wakeup() is called on the resurrected copy, so they're not
> called on the same object.
>

It is the opposite of wakeup() - just like __construct() is the opposite 
of __destruct().  You can't have it both ways.

> Anyway, I must thank you for making me think more thoroughly about this.
>
> Greetings,
> Thomas
>


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

[toc] | [prev] | [next] | [standalone]

#5397

From	"M. Strobel" <sorry_no_mail_here@nowhere.dee>
Date	2012-04-10 10:05 +0200
Message-ID	<9ui7u7FkvdU1@mid.uni-berlin.de>
In reply to	#5393

Am 10.04.2012 02:17, schrieb Jerry Stuckle:
> On 4/9/2012 4:50 PM, Thomas Mlynarczyk wrote:
> 
>> And this initialization is not needed (or might even prove harmful) when
>> the object is copied rather than created from scratch, because in that
>> case the initialization was already done on the original object and the
>> copy was thus created from an already initialized object and it will
>> "inherit" the initialized state. Instead, there are __clone() and
>> __wakeup() which replace __construct() and can do different
>> initialization tasks depending on how the object was created.
>>
> 
> Initialization is NEVER harmful if it is done properly.  That's the whole purpose of
> initialization!.  wakeup() is NOT a constructor - any more than sleep() is a destructor.

'if done properly' fits everywhere and is just too true to be useful.

In PHP the constructor is called on an object without state (data). So you would
normally in the constructor just write out our data, like setting a counter to zero
or a date to the current time. This would be harmful to do on a 'not new' object.

Now PDO comes in. When getting a query result as object your constructor is called
*after* the properties are set.

I found it quite annoying to have an exception from the rule. But thinking more about
it I found out they had a choice of either calling __construct() after setting the
data, or to define another magic method like __pdoconstruct() to give the programmer
a chance to adapt the init process to the data.

Bottom line is: you just have to know your programming language very well, and test
everything thoroughly. Knowledge of OO principles help a lot, but are often too
general to be operational (like for example the "Open Close Principle").

/Str.

[toc] | [prev] | [next] | [standalone]

#5402

From	Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de>
Date	2012-04-10 13:28 +0200
Message-ID	<jm15hg$eh8$1@news.albasani.net>
In reply to	#5397

M. Strobel schrieb:

> Now PDO comes in. When getting a query result as object your constructor is called
> *after* the properties are set.

Really? That would be very strange indeed.

[minutes later]
I just tested it and it is indeed as you state. Thanks for pointing that 
out -- is this documented?

> I found it quite annoying to have an exception from the rule. But thinking more about
> it I found out they had a choice of either calling __construct() after setting the
> data, or to define another magic method like __pdoconstruct() to give the programmer
> a chance to adapt the init process to the data.

I don't quite follow you here. Why did they have no choice? I don't see 
why they (c|sh)ould not call the constructor before setting the data. 
After all, that would be the only logical and sensible thing to do. If 
you would do this "manually", you would do it like this:

foreach ( $rows as $row ):
     $item = new MyClass( 'foo', 'bar' );
     foreach ( $row as $name => $value ):
         $item->$name = $value;
     endforeach;
     $result[] = $item;
endforeach;

And I guess it would be impossible to do it the other way round (first 
setting data, then calling constructor). The setting of the data can be 
controlled using the magic __set() method, so there's no need for 
__pdoconstruct(), if I understand you correctly.

A more intelligent approach may have been to define an interface which 
any "result row" class must implement and which defines a method like 
setData( $rowAsArray ). Or maybe even better: make use of the existing 
__set_state() magic method.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

#5429

From	"M. Strobel" <sorry_no_mail_here@nowhere.dee>
Date	2012-04-10 18:54 +0200
Message-ID	<9uj6u0F2j6U1@mid.uni-berlin.de>
In reply to	#5402

Am 10.04.2012 13:28, schrieb Thomas Mlynarczyk:
> M. Strobel schrieb:
> 
>> Now PDO comes in. When getting a query result as object your constructor is called
>> *after* the properties are set.
> 
> Really? That would be very strange indeed.
> 
> [minutes later]
> I just tested it and it is indeed as you state. Thanks for pointing that out -- is
> this documented?
> 
>> I found it quite annoying to have an exception from the rule. But thinking more about
>> it I found out they had a choice of either calling __construct() after setting the
>> data, or to define another magic method like __pdoconstruct() to give the programmer
>> a chance to adapt the init process to the data.
> 
> I don't quite follow you here. Why did they have no choice? I don't see why they
> (c|sh)ould not call the constructor before setting the data. After all, that would be
> the only logical and sensible thing to do. If you would do this "manually", you would
> do it like this:
> 
> foreach ( $rows as $row ):
>     $item = new MyClass( 'foo', 'bar' );
>     foreach ( $row as $name => $value ):
>         $item->$name = $value;
>     endforeach;
>     $result[] = $item;
> endforeach;
> 

Meanwhile I have more ideas about choices.

The correct way would have been to pass the row to the constructor. This would have
required a matching parameter definition for the constructor, and the corresponding
code, quite error prone.

In your example above the problem is if you need to do more init work on the data you
need an extra method call. With the implemented solution you just have to know that
the constructor is called after setting the vars, and you can detect it, testing the
unique key or so, but need not do so if you don't care.

> And I guess it would be impossible to do it the other way round (first setting data,
> then calling constructor). The setting of the data can be controlled using the magic
> __set() method, so there's no need for __pdoconstruct(), if I understand you correctly.

Are you aware of the fact that __set() is not called for defined variables? Test:
<?php
class Upset {
    public $var1;
    function __set($n, $v) {
        echo "setting variable $n to: $v\n";
        $this->$n = $v;
    }
}
$c = new Upset();
$c->var1 = 'Try this';
$c->another = ' and this ';
echo "Values are now $c->var1 $c->another\n";
------------------- Result: ----
setting variable another to:  and this
Values are now Try this  and this


> A more intelligent approach may have been to define an interface which any "result
> row" class must implement and which defines a method like setData( $rowAsArray ). Or
> maybe even better: make use of the existing __set_state() magic method.

The rationale (or use case) of __set_state() is a mystery to me.

Maybe they did not want to ask too much from PHP programmers...

/Str.

[toc] | [prev] | [next] | [standalone]

#5435

From	Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de>
Date	2012-04-10 20:10 +0200
Message-ID	<jm1t2v$372$1@news.albasani.net>
In reply to	#5429

M. Strobel schrieb:

> In your example above the problem is if you need to do more init work on the data you
> need an extra method call. With the implemented solution you just have to know that
> the constructor is called after setting the vars, and you can detect it, testing the
> unique key or so, but need not do so if you don't care.

Hm, yes, but it still feels wrong to me that the constructor call is not 
the very first thing happening to the object.

> Are you aware of the fact that __set() is not called for defined variables?

Yes, it's not called for defined /public/ variables. But you rarely have 
public variables in your classes.

> The rationale (or use case) of __set_state() is a mystery to me.

Well, it's used by var_export() when exporting objects. For example,

     $a = (object) array( 'foo' => 'bar' );

will be exported as

     stdClass::__set_state(array( 'foo' => 'bar', ))

even though PHP should know very well that stdClass has no such static 
method. Consequently, writing the output of var_export() to a file and 
then re-including it, will fail, thus defeating the whole purpose of 
var_export(). Test code:

     $a = (object) array( 'foo' => 'bar' );
     $s = var_export( $a, true );
     var_dump( $a, $s );
     $b = eval( "return $s;" );
     var_dump( $b );

But __set_state() seems to be some sort of "factory method" which is 
called as a static method on a class, passing an array with "state 
information" and the method is supposed to create an object, set its 
state using the passed array and return the new object. And that would 
be exactly what PDO needs to set the data of the row object: no need to 
define an array with extra constructor arguments -- just tell PDO the 
class name and make sure the class has a __set_state() method defined. 
But alas, it's not what PDO does.

Greetings,
Thomas

-- 
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →

csiph-web

out of sheer curiosity...

Contents

#5262

#5265

#5368

#5369

#5373

#5374

#5376

#5375

#5378

#5379

#5380

#5381

#5382

#5383

#5387

#5393

#5397

#5402

#5429

#5435