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.



On 5/18/05, Lukas Smith <[EMAIL PROTECTED]> wrote:
> Nicholas Telford wrote:
> 
> > What I'm proposing is to allow PDO::query() to return a subclass of
> > PDOStatement. This would allow abstractions to tailor the result set to
> > their own needs while not (in theory) being too complicated to implement.
> >
> > My initial idea involves passing an object that is a subclass of
> > PDOStatement into PDO:query as a second parameter, then all that would
> > be needed to get it to return a custom result set would be something
> > like this:
> 
> http://oss.backendmedia.com/index.php?area=PDO&page=FAQ
> 
> read the last item over there.
> 
> Marcus (IIRC) is planning on making this less clumsy as right now you
> have to repeatedly specifiy the statement class you want AFAIK.
> 
> regards,
> Lukas
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to