Derick Rethans wrote:
On Tue, 17 May 2005, Timm Friebe wrote:
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
Oops, and here a patch without the debug fprintf :-)
- Chris
Index: ext/standard/var_unserializer.c
=
Derick Rethans wrote:
On Tue, 17 May 2005, Timm Friebe wrote:
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
I attached a patch for ext/standard/var_unserializer.{c,re}
- Chris
Index: ext/standard/var_unserializer.c
===
I've been going over PDO lately and I noticed that PDO::query() always
returns a PDOStatement object. Now for the most part, this is fine, but
it got me thinking.
It's been said many times that PDO is not an abstraction layer, it's
more of a unified interface, however, having PDO::query() alway
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 subcl
Lukas Smith 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 ob
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 buildi
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
parent::method() should work, but the point is that if you add a foo()
method in a class that extends PDO, at a time where there is no
PDO::foo(), and you make it work in a particular way, and 6-18 months
later, when PDO::foo() gets added and does something totally
different. Now, someone else is
Wez Furlong wrote:
parent::method() should work, but the point is that if you add a foo()
method in a class that extends PDO, at a time where there is no
PDO::foo(), and you make it work in a particular way, and 6-18 months
later, when PDO::foo() gets added and does something totally
different. No
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 Fram
10 matches
Mail list logo
