Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43144
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.154 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=wGiuzrBnKckGM7t1znaLyLZh/mdg3FyWUlydg8E7RXturqUTBikesUAG7+x0hyM128
         B21pdwMvg6F4ctXiXVTXzJHk6G5jcRShda/lLlK4WGNRDroACrGEkY22xwrVrL7MGtra
         2+Ftwjs2O9JQegY20NQo1rhk/WMxHXzDEi8zo=
MIME-Version: 1.0
In-Reply-To: <1485774593.20090221130543@marcus-boerger.de>
References: <7dd2dc0b0902172008g5a634577pad280d1f0415453b@mail.gmail.com>
	 <499BC82B.2000000@daylessday.org> <1234963004.5869.6.camel@goldfinger>
	 <7dd2dc0b0902180631q359a189aj5e4c54ef96d7f8e0@mail.gmail.com>
	 <8210197104.20090219001447@marcus-boerger.de>
	 <1235041029.5869.28.camel@goldfinger>
	 <fe05d1540902190322i2208af4dn4baeef9adfda99b@mail.gmail.com>
	 <1485774593.20090221130543@marcus-boerger.de>
Date: Sat, 21 Feb 2009 14:46:01 +0100
Message-ID: <fe05d1540902210546m7ba68fc2j35007033c5d0a959@mail.gmail.com>
To: Marcus Boerger <helly@php.net>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>, 
	Nathan Nobbe <quickshiftin@gmail.com>, Antony Dovgal <tony@daylessday.org>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Feb 21, 2009 at 1:05 PM, Marcus Boerger <helly@php.net> wrote:
> Hello Pierre,
>
> Thursday, February 19, 2009, 12:22:41 PM, you wrote:
>
>> hi,
>
>> On Thu, Feb 19, 2009 at 11:57 AM, Johannes Schl=FCter <johannes@php.net>=
 wrote:
>
>>> ps. I'm aware of the fact that we added some specific APIs in special
>>> cases in bug fix releases before, but there's a difference between
>>> adding APIs and breaking the ABI of existing, used, stuff.
>
>> Exactly. To summarize:
>
>> x.y.z to x.y.z+1: ABI and API must be 100% compatible
>> x.y.z to x.y+1.z: ABI can be broken (need a recompilation), =A0API must
>> be 100% compatible
>> x.y.z to x+1.y.z: party time ;)
>
> That's completely untrue.

In your mind maybe, but if we do not follow these simple rules then we
have a serious problem.

> What we ensure is that function f introduced in
> x.y.z stays in all verisons x.y.z+n and keeps its exact semantics.

We have been wrong in the past and changed API between minor version,
it was a major mistake. In the meantime, we have tried to do not do it
again.

x.y.z and x.y.y+1 has not only have to keep the same sematic,
behaviors but also the same signatures as well as a binary
compatibility. One bad example was a change we made in 5.2.x making it
incompatible with previous versions, there was no version id chante
and it was a pain to change the extensions to be compatible with the
full 5.2.x serie. The worst is that I can't even figure out when it
happens without looking at the code (maybe 5.2.5? :)

> What we
> did not ensure ever, is that version x.y.z+1 does not come with a functio=
n
> g that did not exist in x.y.z.

That's no problem, as long as the x.y.z+1 API is 100% compatible with
x.y.y. New functions do not break existing functions signature or
behaviors, obviously.

> Same obviously applies to consts and yes
> macros, which have nothing to do abi or api. And actually abi has nothing
> to do with the whole discussion. The ABI influences how a binary gets
> layout,

ABI has to do with the discussions as a given binary has to work
across the same minor versions. It causes the same problem but with
different origins.

> and in that way determines how a user of said binary can access the
> API elements (consts, function, classes,...). This obviously affects DLLs
> on windows and shared objects on *nix. Either way, adding more macros and
> new functions is fine, as lone as we do not change any existing function
> protocol.

Exactly what I said. New functions do not break the API and it is
possible to modify a struct without breaking existing binary
compatibility.


> The new patch is clean enough to me and doesn't change the API. Whether t=
he
> ABI changes depends on the compilers and linkers.

My comment was a general comment on what should be the policy, not
specifically about this patch :)

All in all it seems that you are saying the same than I did, only with
different wording :)

Cheers,
--=20
Pierre

http://blog.thepimp.net | http://www.libgd.org