On Thu, Jun 3, 2010 at 8:07 PM, Jonathan Wage <jonw...@gmail.com> wrote:
> Hi, > > On Thu, Jun 3, 2010 at 1:58 PM, Ferenc Kovacs <i...@tyrael.hu> wrote: > >> >> >> On Thu, Jun 3, 2010 at 7:28 PM, Jonathan Wage <jonw...@gmail.com> wrote: >> >>> Hi, >>> >>> On Thu, Jun 3, 2010 at 1:16 PM, Ferenc Kovacs <i...@tyrael.hu> wrote: >>> >>>> If that so, I would be happy to see some discussion and work on the PDO, >>>> because from a user perspective, it seems like abadoned. >>>> I think that we should allow to get things commited, because: >>>> 1, the trunk is a trunk, if something gets commited, it doesn't mean, >>>> that it will be merged for the release. >>>> >>> >>> Ok, that is a valid argument. But lets be real here. Chances are that if >>> it makes it into trunk, nobody will say anything and it will make it into >>> the final release. >>> >> >> I disagree here, but if nobody will solve this situation until the next >> release, then I think its better to have _something_, than chasing away >> people who are contributing, and waiting something to happen. >> >> > > Aren't some of the other core developers willing to work together to design > something to handle this? From my few discussions with Pierre it seems like > that is what he wants to do and is willing to be a part of it. > As far as I know, Pierre contributes a LOT, but I dunno that he has any spare time to be involved with the actual work, but he will say this for himself. > > >> Take a look at the inconsistency of PHP as a whole and you'll see that >>> this is not really a good idea. If someone, somewhere commits something it >>> can make it into PHP and that's why PHP is in the state it is in today. >>> >> >> So? >> Now we shouldn't try to improve things because they aren't perfect? >> > > No, we should work together to come up with a proper long term solution. > > I think that the only thing that block this is the actual work. > >> >>> We need to stop this and start fixing it today. >>> >> >> Go ahed. >> Do you have any timeline for it? >> > >> > > :) I'll talk with the core developers I know and see what we can make > happen. I'll do whatever is needed to ensure this does not get committed. > > I think you have great chances to stop this patch to be merged into the trunk. But doing this is pointless if we can't go as far as actually discuss, plan, and _implement_ the proper solution for this problem. > If you don't agree, you are in denial. The API of PHP now is proof. >>> >>> >> >> I'm agree, I'm just not seeing any progress, only excuses why should we >> wait for the great improvement, that should be happen anytime soon... >> >> >>> 2, it can start a healty discussion and brainstorming about the current >>>> problem, and the solution. >>>> >>>> >>> We're already discussing it. We don't have to commit something that is >>> obviously wrong in order to do that. >>> >>> >> >> Where? >> The last modification in the manual was in january, and the only >> discussion recently on php.pdo is about extending pdo with two driver >> specific(both are for postgresql, one of them is this that we are talking >> about) feature. >> http://news.php.net/group.php?group=php.pdo >> >> So this is why I said, that there is no progress, just holding back the >> people like Denis who are willing to help, making the patch, sorting out the >> problems, writing testcases, doing the groundwork. >> >> If there will be a better solution(like the ones what we discussed above), >> and somebody will actually implement that, then this feature can be reverted >> as well. >> But right now I didn't see any work in that direction. >> >> > Isn't it possible for Denis to take our recommendations and tweak his work > to take into account those things? > > He expressed his willingness in this case. If he is interested in contributing it seems like this would be the obvious > thing to do. I agree it would be nice to have those things in PHP, so can he > tweak his patch to be a more proper long term solution? > > He can, but if we can't agree on (in a finite amount of time) what is proper, then he can't pass that criteria. Tyrael
