Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81588
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
In-Reply-To: <CAPwsocELvXd+f2f_7-CeDB-=dQkM43yxZ5y3je8R9Tk8-0OYPw@mail.gmail.com>
References: <CAH8MpnktGy27BGFyH9i+tdfuMbti8KzHEXp=KD5LWy0vnKtxMw@mail.gmail.com>
	<CAPwsocELvXd+f2f_7-CeDB-=dQkM43yxZ5y3je8R9Tk8-0OYPw@mail.gmail.com>
Date: Mon, 2 Feb 2015 09:30:56 -0500
Message-ID: <CAH8MpnmumQFq8=JHQhq-uGe+dPW+jQDfR7O93xk1v=800ekRvw@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Jakub Zelenka <bukka@php.net>
Content-Type: multipart/alternative; boundary=001a113ed8986eee6b050e1bcdbb
Subject: Re: [PHP-DEV] Re: OpenSSL ext. improvements for authenticated cipher modes.
From: rdlowrey@php.net (Daniel Lowrey)

--001a113ed8986eee6b050e1bcdbb
Content-Type: text/plain; charset=UTF-8

> The extra params aren't really _that_ bad.

Okay, I'd like to reset the conversation a bit here. It's clear that the
current API does not fit the problem domain very well. Tacking on more
parameters only creates a bigger mess. Six parameters to a stateless
function call is a completely incoherent API. It's unusable without
consulting the manual. I think we need a completely different approach. Let
me propose something else that won't break BC in any release and results in
an API that's actually sane:

class CryptoContext {
    private $mode;
    private $password;
    function __construct($mode, $password) {
        $this->mode = $mode;
        $this->password = $password;
    }
    function encrypt($data) {
        // ...
        return $encryptedData;
    }
    function decrypt($data) {
        // ...
        return $decryptedData;
    }
    function setOption($option, $value) {
        // ...
    }
    // more methods here to do anything you need
}

Thoughts on a stateful object API here? Personally I find this much more
coherent than anything that's been proposed so far and it could be
implemented without affecting existing functionality.

--001a113ed8986eee6b050e1bcdbb--