Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <2cee1fe1-6dfd-0337-7286-42f873b9f508@gmx.de>
 <CAL=_i_nAcS4puEKGxn6dU4MkSepf4sMEvv-EgpmBgEnfgOVDKQ@mail.gmail.com>
 <67.91.31343.AD0F3785@pb1.pair.com>
Message-ID: <3d4917f6-98b6-3f33-ca92-d95ceeeceb0c@gmx.de>
Date: Tue, 10 Jan 2017 00:08:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <67.91.31343.AD0F3785@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] ext/gd: support creation of animated GIFs
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 09.01.2017 at 21:21, Andrea Faulds wrote:

> Joe Watkins wrote:
>
>> We have to face facts: Resources are still a thing.
>>
>> While there is talk of switching resources to use opaque objects, I'm
>> worried about introducing a mixture of objects and resources in random
>> places throughout core exts, and having exts with both seems very strange
>> to me.

ACK.

>> I know that this has already started to happen, but before it goes any
>> further I would implore you to stick to resources for now.
> 
> The more things are made objects now, the less things need to be
> converted to be objects later.

ACK.

> It might be “strange” to mix them, but would it actually cause
> confusion? So far as the user cares, resources and objects returned by
> Gd could just be integers. They're just opaque handles.

I think that they *should* be opaque handles, but you never know how
one's going to treat them.  Presumably the most crucial point nowadays
are type declarations; changing a resource to be an object could cause
massive BC break (think of streams) – changing all resources to objects
appears to be even impracticable for a major version.  Therefore I think
this has to be done in small steps ("eating the elephpant one bite at a
time"), and so introducing new opaque handles as objects appears
somewhat sensible even if that causes a mix of resources and objects in
a single extension.

Anyhow, I understand that the animated GIF support will need an RFC, and
there should be a secondary voting option whether the API should use a
resource or an opaque object.

-- 
Christoph M. Becker