On 24 May 2010 13:09, Zeev Suraski z...@zend.com wrote:
I see three key options going forward:
1. Implement the table along the lines of what it looks like now, perhaps
with minor changes.
2. Implement identical conversion rules to the ones that exist in PHP; That
effectively turns type
Because that is, IMO, a bad precedent to start for PHP internal
functions. Too many functions already produce warnings (fopen) and
return a status that can be checked. The solution right now is @ and
that has so much baggage with it that you can now disable that feature
completely making
On Mon, May 24, 2010 at 2:12 PM, Brian Moon br...@moonspot.net wrote:
Because that is, IMO, a bad precedent to start for PHP internal functions.
Too many functions already produce warnings (fopen) and return a status that
can be checked. The solution right now is @ and that has so much baggage
Hi.
I developed some patches for PDO/Postgresql driver in order to add some useful
methods that were available in the original pgsql driver.
The attached patches apply on 5.3.2 and svn 5.3.x.
If needed, i have patches also for 5.2.x.
Please comment and tell me improvements or tips.
Thank you
Denis Gasparin wrote:
Hi.
I developed some patches for PDO/Postgresql driver in order to add some
useful \
methods that were available in the original pgsql driver.
p...@lists.php.net is the right place for PDO development ;)
Ops sorry :-) I will post the patches also to that list.
But
hi,
I will apply the patch to trunk later today as it seems that we have
no objection for the patch itself. The proposal to add more
information on failure can be implemented later, if someone fills
motivated enough to do it.
Cheers,
--
Pierre
On Sat, May 22, 2010 at 5:28 PM, Pierre Joye
On Mon, May 24, 2010 6:09 am, Zeev Suraski wrote:
At 03:53 24/05/2010, s...@geleia.net wrote:
On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
On Sat, May 22, 2010 at 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider
strict type
On Mon, May 24, 2010 at 1:48 PM, s...@geleia.net wrote:
I think the best option is to align the type checking with
zend_parse_parameters (this is not the same as an implicit cast) and make
it stricter. This includes:
* disallow string to float/int when it contains non-numeric characters
At 14:48 24/05/2010, s...@geleia.net wrote:
Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.
I disagree. The === operator already checks the type of the variables.
We can agree to disagree regarding the level of understanding the
average PHP developer has
On Mon, May 24, 2010 1:12 pm, Zeev Suraski wrote:
Sounds acceptable to me, that's along the lines of the 3rd option
which appears to be getting the most traction. I'd also no conversion of
arrays to scalars to that list.
Arrays to scalars already fail. See
Hey Ralph
2010/5/21 Ralph Schindler ra...@smashlabs.com:
Hey all,
The first patch is against trunk. I think we should at least get this done
even if the group decides that down the line we want the why portion
explained as well (I actually don't care about the why part). That feature
Hi Zeev:
On Mon, May 24, 2010 at 08:09:30AM +0300, Zeev Suraski wrote:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in PHP;
That effectively turns type hinting into scalar
At 18:39 24/05/2010, Daniel Convissor wrote:
On a side note, I hope the hinting will allow the ability to do something
something like int|null for graceful handling of optional parameters.
There was an idea to allow null if you use 'int foo = null' - but
only that particular use case (e.g.,
Stas Malyshev wrote:
Hi!
I see three key options going forward:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
PHP; That effectively turns type hinting into scalar casting
Hi!
In case we remove 'Array-scalar' and others everywhere, #3 would be the
same as #2. I'm for that.
AFAIK parse_parameters already rejects Array-scalar, so if we can tweak
it so that it would make sense for all cases, even better.
As for implicit/explicit casts, I'm not sure - it might make
Dmitry Stogov wrote:
http://wiki.php.net/rfc/runtimecache
The patch breaks binary and source compatibility but it's not hard to
adopt extensions to use it.
Hi Dmitry,
Can update the RFC to explain the breakage and
It's clear from the patch. The same is explained in RFC in
Hi!
If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
That's probably not so. As I understand, the patch changes the way the
object properties are accessed. So if your
since when? PDO was designed to allow drivers to provide their own
functions, which many drivers do.
On Mon, May 24, 2010 at 5:16 AM, Lester Caine les...@lsces.co.uk wrote:
Denis Gasparin wrote:
Hi.
I developed some patches for PDO/Postgresql driver in order to add some
useful methods that
Denis,
Could you merge the patches into a single for easier code review. Also, the
copy to/from file seems like it would just be a wrapper against the native
COPY PostgreSQL command, is there really a need to provide a method for it?
On Mon, May 24, 2010 at 4:57 AM, Denis Gasparin
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.
Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
http://wiki.php.net/rfc/runtimecache
The patch breaks binary and source compatibility but it's not
hard to
adopt
hi Ilia,
On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky i...@prohost.org wrote:
since when? PDO was designed to allow drivers to provide their own
functions, which many drivers do.
We discussed that on the PDO list, and we try to avoid to add drivers
specific methods. That's obviously makes
On 24.05.2010, at 22:04, Pierre Joye wrote:
hi Ilia,
On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky i...@prohost.org wrote:
since when? PDO was designed to allow drivers to provide their own
functions, which many drivers do.
We discussed that on the PDO list, and we try to avoid to
On Mon, May 24, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com wrote:
Limiting ourselves to Least Common Denominator is not the best idea.
And adding vendors specific stuff all around is a very bad idea. See
the ones we have now in PDO::
I think it is time to figure how we can do it in
Pierre,
As one of the original authors of PDO that is news to me. PDO was designed
to allow common functionality to be provided via a common interface, however
it was also designed to recognize that not all database interfaces are the
same. And as such allowed driver authors to provide custom
I think Kalle's patch is a really good solution for the trunk. +1
On Mon, May 24, 2010 at 8:51 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Hey Ralph
2010/5/21 Ralph Schindler ra...@smashlabs.com:
Hey all,
The first patch is against trunk. I think we should at least get this
done
On Mon, May 24, 2010 at 8:56 PM, Ilia Alshanetsky i...@prohost.org wrote:
Pierre,
As one of the original authors of PDO that is news to me. PDO was designed
to allow common functionality to be provided via a common interface, however
it was also designed to recognize that not all database
hi,
On Mon, May 24, 2010 at 8:58 PM, Ilia Alshanetsky i...@prohost.org wrote:
I think Kalle's patch is a really good solution for the trunk. +1
Same here, with a couple of changes like killing the warning (and the
related flag) as well as removing the duplicated code. I will do that
before
On 24.05.2010 21:54, Ilia Alshanetsky wrote:
Denis,
Could you merge the patches into a single for easier code review.
Hint: `diff -u` produces a bit more human-readable patch.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime
Hi!
The patch below seems to fix ext/intl (and maybe others) compile
problems on Mac OS X. The problem seems to be because C++ needs
libstdc++ and for some reason it doesn't get added on Mac.
Could people having build problems on Mac see if this fixes the problem
for them
I'll provide the patches in a single file as soon as possible.
Actually all the methods are wrappers against the native PostgreSQL commands
(connection status, copy to/from).
I needed to develop them as methods because it is not possible to get the same
results with a sql statement (in
I attached the patch as a single file.
There are currently no tests written for the new methods.
I'll provide them if needed to integrate the patch in the pdo_pgsql driver.
Denis
- Messaggio originale -
Da: Denis Gasparin denis.gaspa...@edistar.com
A: Ilia Alshanetsky
Thanks Dmitry - that's great.
Also thanks to Stas for his reply.
Chris
Dmitry Stogov wrote:
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.
Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
Pierre Joye wrote:
On Mon, May 24, 2010 at 8:56 PM, Ilia Alshanetskyi...@prohost.org wrote:
Pierre,
As one of the original authors of PDO that is news to me. PDO was designed
to allow common functionality to be provided via a common interface, however
it was also designed to recognize that not
Denis could you elaborate on what makes use of the COPY code via Sql
behave differently then a PHP method call?
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2010-05-24, at 15:45, Denis Gasparin denis.gaspa...@edistar.com
wrote:
I'll provide the patches in a single file as soon as possible.
On Mon, May 24, 2010 at 10:46 PM, Christopher Jones
christopher.jo...@oracle.com wrote:
Thanks Dmitry - that's great.
I second that, useful info for people with time issues like us :)
Also thanks to Stas for his reply.
Chris
Dmitry Stogov wrote:
Hi Chris,
I've added notes for
The copy to/from sql statements accept both as main parameter a filename or
stdout/stdin respectively.
The filename represents a file in the database filesystem (apache/php and
postgresql must reside on the same machine or share the file via shared
filesystem). I quote from the postgresql
On Mon, 2010-05-24 at 14:56 -0400, Ilia Alshanetsky wrote:
As one of the original authors of PDO that is news to me. PDO was designed
to allow common functionality to be provided via a common interface, however
it was also designed to recognize that not all database interfaces are the
same.
On May 24, 2010, at 12:42 PM, Stas Malyshev wrote:
Hi!
The patch below seems to fix ext/intl (and maybe others) compile problems on
Mac OS X. The problem seems to be because C++ needs libstdc++ and for some
reason it doesn't get added on Mac.
Could people having build problems on Mac
On Tue, May 18, 2010 8:22 am, Dmitry Stogov wrote:
I'm proposing another optimisation technique implementation for PHP
which makes up to 20% speed up on synthetic tests and up to 8% speed up on
real-life applications.
The technique is similar to inline caches which is very popular in JIT
39 matches
Mail list logo
