Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46888
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 26 Jan 2010 14:02:01 +0000 (GMT)
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@php.net>
cc: Matt Read <matt@mattread.com>, internals@lists.php.net, 
    Pierrick Charron <pierrick@php.net>, Ilia Alshanetsky <iliaa@php.net>
In-Reply-To: <1264497076.3201.74.camel@guybrush>
Message-ID: <alpine.DEB.2.00.1001261401370.2010@kossu.derickrethans.nl>
References: <1263606897.3850.27.camel@elisa> <1264497076.3201.74.camel@guybrush>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2137735440-1264514521=:2010"
Subject: Re: [PHP-DEV] PDO Bug introduced in revision 290786 and released in
 5.2.12 and 5.3.1
From: derick@php.net (Derick Rethans)

--8323329-2137735440-1264514521=:2010
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 26 Jan 2010, Johannes Schl=C3=BCter wrote:

> On Fri, 2010-01-15 at 20:54 -0500, Matt Read wrote:
> > We are developers from the Habari Project, an open source PHP blogging
> > application; We would like to raise concern with a recent change to the
> > logic of PDO.
> >=20
> > We believe that PHP's revision 290786 [1] should not have been committe=
d
> > (see bug 49521 [2]). This changed the behaviour of PDO so that an
> > object's constructor is called before the properties from the database
> > fields are set.
>=20
> Any more comments on this one? - The more I think Matt is right on this
> one especially as the PROPS_LATE constant exists in this case.
>=20
> We have two similar cases:
>=20
> in regards to tidy:
> http://svn.php.net/viewvc?view=3Drevision&revision=3D292620
> and in regards to mysqli:
> http://svn.php.net/viewvc?view=3Drevision&revision=3D293039
>=20
> A problem with these changes is that the old behavior made it possible
> to do further object initialization once the data had been provided by
> using a constructor. With the new code the user has to add an "init"
> method of some kind which is called after fetching the data as
> object ...
>=20
> The old behavior might be wrong from an OO-puristic point of view, but
> that isn't fixed, actually as the properties are still randomly set.
>=20
> I think best is to revert these 3 changes from 5.2, 5.3 and trunk and
> make it clearer in the docs.

Yup, I agree.

Derick

--=20
http://derickrethans.nl | http://xdebug.org
twitter: @derickr
--8323329-2137735440-1264514521=:2010--