Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100294 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28006 invoked from network); 23 Aug 2017 22:06:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Aug 2017 22:06:56 -0000 Authentication-Results: pb1.pair.com header.from=adambaratz@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=adam.baratz@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.180 as permitted sender) X-PHP-List-Original-Sender: adam.baratz@gmail.com X-Host-Fingerprint: 209.85.220.180 mail-qk0-f180.google.com Received: from [209.85.220.180] ([209.85.220.180:34217] helo=mail-qk0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/DF-34801-F7CFD995 for ; Wed, 23 Aug 2017 18:06:55 -0400 Received: by mail-qk0-f180.google.com with SMTP id p67so2838672qkd.1 for ; Wed, 23 Aug 2017 15:06:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=idWUlY8GVrcptsrHtT7nKXW8u6pTZSNPq/hm/XLU8js=; b=AjxCh/uajHY1fP0xtq7KEXpUcI0AEXJi4KEZRzd08VZ+5mof63Slg7z6CiKFfPAloa PFktFX8U+ruaxijuH/LHWzPMdPq3MTbWdp9pmpuRD8LadoRGCKmciN8ApdNbwDW+q/TH 296ifcQMXmA5cDcdkfy4w9W4EDn185/bsG6k39aUsayPIT+UD6UpytaU/UMtEluGSD/2 Ujd34q2Rp7n9wLayCHuqDhe+dcZs7KsRQxBnYS8/6bzN3vqP1xnH9X4k3kdSP9geyaam kTwqNn+n8QPwmkXSTlqTXuIOGF4/CldJp2cYRNoDyfW4R4vnG45GPntQHR3f039pCFvw CUWA== X-Gm-Message-State: AHYfb5hKJTviuYbnQvmDScOtlWt+fKhb8X/7Gum9eZ3a87eB4cGUj+wP xgGjTGMCcG8uWOorubI= X-Received: by 10.55.54.84 with SMTP id d81mr5384979qka.143.1503526012544; Wed, 23 Aug 2017 15:06:52 -0700 (PDT) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id s36sm1570345qts.77.2017.08.23.15.06.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 15:06:51 -0700 (PDT) Received: by mail-qt0-f179.google.com with SMTP id v29so7576216qtv.3 for ; Wed, 23 Aug 2017 15:06:51 -0700 (PDT) X-Received: by 10.200.22.47 with SMTP id p44mr5536196qtj.97.1503526011092; Wed, 23 Aug 2017 15:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.199 with HTTP; Wed, 23 Aug 2017 15:06:50 -0700 (PDT) In-Reply-To: References: <1e398f12adbdbed6b7caf3b0af07f284@bohwaz.net> <069c08bfe15b856007debab5d0d961be@bohwaz.net> Date: Wed, 23 Aug 2017 18:06:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "BohwaZ/PHP" Cc: Marco Pivetta , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="f403045d7222cd46a0055772ed6d" Subject: Re: [PHP-DEV] Matching PDO_SQLite features with SQLite3 extension From: adambaratz@php.net (Adam Baratz) --f403045d7222cd46a0055772ed6d Content-Type: text/plain; charset="UTF-8" > > That change was implemented in the SQLite3 extension without a RFC, so I'm > quite confused here. > My literal reading of the contribution guide[1] is that new features should be preceded by an RFC, though there are certainly cases where this doesn't happen. I don't have a clear enough understanding of this community to say when RFCs can be skipped. I'm not sure who the authority would be. The release manager for the next minor rev? Anyone with commit privileges? I kinda feel like it's a weird thing to submit an RFC that would basically > ask the question "should pdo_sqlite only implement a subset of SQLite", > because well it is most likely that if you are using a DB driver with PDO > you most likely want to be able to access that DB features, no? > > Or are you saying that we should have a vote on whether the implementation > should follow what is already existing in PDO or should propose something > new instead? Because I frankly don't know what would be a better idea than > driver-specific methods and I don't know enough C/have enough time to do > anything else, so I won't submit any proposition that I won't be able to do > myself. > Only speaking for myself: I'd just want the RFC to act as a sanity check that the method you're adding has the right signature and it's being implemented consistently with similar methods. I don't like the design pattern either, but it's not like you're introducing it. It's better for PDO to be feature complete than to have a perfect architecture. A tool missing functionality will be less desirable to use. I'd be more concerned about the consequences of that state. Whoever wants to figure out the right way to support extension-specific methods would have to figure out how to deprecate the existing methods. Adding one wouldn't really change the scope of this problem, which isn't intractable in the greater scheme of things. Thanks, Adam --- [1] https://github.com/php/php-src/blob/master/CONTRIBUTING.md --f403045d7222cd46a0055772ed6d--