Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

PDO\sqlite_open_blob($pdo, ...). And no, just because a lot of folks jumped from the bridge doesn't make jumping from the bridge acceptable. You can pursue the approach, but you will get a negative vote from over here: that's also where my influence stops though. On 23 Aug 2017 7:15 AM, "BohwaZ/P

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

Le 23/08/2017 16:57, Marco Pivetta a écrit : I suggest adding dedicated functions that given a PDO instance and the parameters you needed do what you want to do. So if I understand correctly: $pdo = new PDO('sqlite::memory:'); $extended = new PDO_Extended_SQLite($pdo); $blob = $extended->openB

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

I suggest adding dedicated functions that given a PDO instance and the parameters you needed do what you want to do. And yes, you are adding new stuff: php-src has this widespread misunderstanding that "reproducing new lower layer behaviour in upper layers" should happen no matter what. On 23 Au

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

PDO is already a mess, and adding method that appear/disappear dynamically whether you enable an extension or not... is a horror show. From my PoV, since we (doctrine) have to abstract away from it all the time, we'd rather have it as tidy and well-thought-out as possible, especially since there

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

PDO is already a mess, and adding method that appear/disappear dynamically whether you enable an extension or not... is a horror show. >From my PoV, since we (doctrine) have to abstract away from it all the time, we'd rather have it as tidy and well-thought-out as possible, especially since there

Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension

Yes, because once it lands in core, it sticks around for almost eternity. Yeah but is it necessary for something that is just missing, because the pdo_sqlite implementation is incomplete, and is basically following what already exists, without changing anything? That change was implemented i

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2017-08-21

Results for project PHP master, build date 2017-08-21 19:23:03-07:00 commit: 1287c20 previous commit:80745e6 revision date: 2017-08-21 19:38:44+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] PHP 8 (or earlier) RFC Proposal

Hi, Dan Ackroyd wrote: On 19 August 2017 at 15:28, Admin NxPoint wrote: Hi, At this moment PHP doesn't know how to use the SWAP memory from linux, Why would it need to 'know' how to use swap memory? My understanding is that the normal way to get a program to use swap memory is to: i) Enab

Re: [PHP-DEV] Contravariance and the "empty type"

On Tue, Aug 22, 2017 at 10:39 AM, Nikita Popov wrote: > On Tue, Aug 22, 2017 at 4:27 AM, Andreas Hennings > wrote: >> >> Hello list, >> for a while I had this thought about contravariance and an "empty type". >> I don't expect too much of it, for now I just want to share the idea. >> Maybe this c

Re: [PHP-DEV] Re: [Request][Discussion] Double value as array key improvement

> On Aug 19, 2017, at 4:30 PM, Nikita Popov wrote: > > On Thu, Aug 17, 2017 at 5:03 PM, Andrew Nester > wrote: > > > > 13 авг. 2017 г., в 21:39, Andrew Nester > > написал(а): > > > > > > > >> 11 авг. 2017 г., в 15:53, An

Re: [PHP-DEV] Contravariance and the "empty type"

On Tue, Aug 22, 2017 at 4:27 AM, Andreas Hennings wrote: > Hello list, > for a while I had this thought about contravariance and an "empty type". > I don't expect too much of it, for now I just want to share the idea. > Maybe this concept even exists somewhere in a different language, and > I am