Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66931
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.210.45 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <66.08.07534.A929C515@pb1.pair.com>
References: <CAESVnVr_jLwRbVsOOx3urPv0Qzc9Rc-7y2CNp1T0mH+8ad3cRg@mail.gmail.com>
	<CAF+90c9N81ZoSpwm2hSh=gCYV2Y3jB1e+N4_N_d_QfHk9JPK5g@mail.gmail.com>
	<CAESVnVrAV4GwhbtUwxez4sAwPboZ1dh=vB2WcW18sv3zt3+MTQ@mail.gmail.com>
	<515C8670.7030400@php.net>
	<66.08.07534.A929C515@pb1.pair.com>
Date: Wed, 3 Apr 2013 20:09:52 -0700
Message-ID: <CAESVnVp_tJ3EGTinfn46XKhiDE4H3ON2o9hisTfRyyop7fhRpg@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Simplified Array API for extensions
From: pollita@php.net (Sara Golemon)

>> A logical extension of this idea would be to drop _array_ and cover
>> objects too, one uniform everything API is very appealing, and way
>> easier to document properly.
>>
>
> https://gist.github.com/krakjoe/5304945
>
> I'd be happy to complete/test it if we think it's a worthy direction to go
> in ... a unified api does look delicious, it's a bit more complex than
> arrays but then in extensions you want/need to deal with objects as much as,
> if note more than, you do arrays ...
>
While I'm in favor of an API which covers both Arrays and Object
properties, I don't want to go too far in the direction of generically
named APIs.  php_exists() is, I think, too far.  I'm not sure what's
the right middle-ground of being both descriptive and concise, but I'm
sure we can sort that out.