Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16279
Return-Path: <nick.telford@ntlworld.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 50793 invoked by uid 1010); 18 May 2005 16:07:40 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 1956 invoked from network); 18 May 2005 15:47:25 -0000
Received: from unknown (HELO ntlworld.com) (127.0.0.1)
  by localhost with SMTP; 18 May 2005 15:47:25 -0000
X-Host-Fingerprint: 81.97.205.128 spc1-hava1-4-0-cust128.cosh.broadband.ntl.com Linux 2.5 (sometimes 2.4) (4)
Received: from ([81.97.205.128:34648] helo=waiter.telford.lan)
	by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP
	id 68/AC-01538-A836B824 for <internals@lists.php.net>; Wed, 18 May 2005 11:47:24 -0400
Received: from [192.168.0.30] (unknown [192.168.0.30])
	by waiter.telford.lan (Postfix) with ESMTP id 01E7739087F;
	Wed, 18 May 2005 16:46:58 +0100 (BST)
Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.11.12]); Wed, 18 May 2005 16:46:56 +0100
Message-ID: <428B636F.1050902@ntlworld.com>
Date: Wed, 18 May 2005 16:46:55 +0100
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wez Furlong <kingwez@gmail.com>
Cc: Lukas Smith <lsmith@php.net>, internals@lists.php.net
References: <20050518132615.55570.qmail@lists.php.net>	 <428B40D7.8030903@php.net> <4e89b426050518083848d9a25@mail.gmail.com>
In-Reply-To: <4e89b426050518083848d9a25@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Allow PDO::query() to return a subclass of PDOStatement
From: nick.telford@ntlworld.com (Nicholas Telford)

Wez Furlong wrote:

>Just like extending any other built-in class, you need to be careful
>to not override built-in methods that either exist now or may exist in
>the future; you can very easily burn yourself 6 months down the track
>this way.
>
>It's generally a bad idea, and definitely something to avoid if you
>are building a class library.
>
>You have now been warned that the traffic is dangerous; if you want to
>go play in it, it's your choice :-)
>
>--Wez.
>  
>
The same could be said for using an external Framework or library 
(except that they'd have the luxury of protecting important methods with 
"final").

I take it parent::method() works with built-in classes?