Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16282
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <428B6684.7040402@php.net>
Date: Wed, 18 May 2005 12:00:04 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Nicholas Telford <nick.telford@ntlworld.com>
Cc: Wez Furlong <kingwez@gmail.com>, internals@lists.php.net
References: <20050518132615.55570.qmail@lists.php.net>	 <428B40D7.8030903@php.net> <4e89b426050518083848d9a25@mail.gmail.com> <428B636F.1050902@ntlworld.com>
In-Reply-To: <428B636F.1050902@ntlworld.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: lsmith@php.net (Lukas Smith)

Nicholas Telford wrote:
> Wez Furlong wrote:

>> 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 :-)

> 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?

err Wez do you think this should really be the case? This will make the 
idea that further levels of abstraction be implemented in userland kinda 
needlessly hard. This will mean that you need to wrap rather than 
extend. Or let me rephrase: I would very much appreciate it if an 
explicit extra effort (triple E) would be made to prevent these kind of 
situations. Obviously as new functionality is added there might be 
issues. Then again atleast we two dont seem to have a large overlap in 
method naming :-)

regards,
Lukas