Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: "M. Strobel" <sorry_no_mail_here@nowhere.dee>
Newsgroups: comp.lang.php
Subject: Re: out of sheer curiosity...
Date: Tue, 10 Apr 2012 20:23:01 +0200
Lines: 51
Message-ID: <9ujc45Fae4U1@mid.uni-berlin.de>
References: <jksrmr$rgq$1@dont-email.me> <17777949.TfjZNtg3zH@PointedEars.de> <jl0boo$461$1@dont-email.me> <9tij5fFmi8U1@mid.uni-berlin.de> <jl1bei$ckh$1@dont-email.me> <jl1ehv$86a$1@news.albasani.net> <4f74567c$0$6887$e4fe514c@news2.news.xs4all.nl> <jl1omm$hdm$1@dont-email.me> <4f746ff9$0$6918$e4fe514c@news2.news.xs4all.nl> <jl2fl0$v97$1@dont-email.me> <9uebvuFt0pU1@mid.uni-berlin.de> <jlsv4m$e1o$1@dont-email.me> <9ueidtFagfU1@mid.uni-berlin.de> <jlta8n$8pi$1@dont-email.me> <9ufofaFvj5U1@mid.uni-berlin.de> <jlukj7$t9t$1@dont-email.me> <jlunmd$qp5$1@news.albasani.net> <jlv19f$9ts$1@dont-email.me> <jlv8cg$2j7$1@news.albasani.net> <jlva9f$22r$1@dont-email.me> <jlvi3a$mpa$1@news.albasani.net> <jlvu7q$peh$1@dont-email.me> <9ui7u7FkvdU1@mid.uni-berlin.de> <jm15hg$eh8$1@news.albasani.net> <9uj6u0F2j6U1@mid.uni-berlin.de> <jm1t2v$372$1@news.albasani.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Trace: news.uni-berlin.de KHzgBDJP1OgL/GXr8kaoZwbKYd6H8Wnz1aLNnsC992rbR7Hms=
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20
In-Reply-To: <jm1t2v$372$1@news.albasani.net>
Xref: csiph.com comp.lang.php:5437

Am 10.04.2012 20:10, schrieb Thomas Mlynarczyk:
> 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.

Still a mystery, why should I want to do var_export()? And your code gives a fatal error.

<shrug> but it's late here, getting dark

/Str.