Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61414
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5006E5BB.50906@sugarcrm.com>
References: <CAN+gjSe7r2SoRNYufcaB2ktK05shH1AcAsaFSbUibF9r4TeRrw@mail.gmail.com>
	<op.whkdiodaidpuyk@damnation>
	<CAEZPtU5Rb9W8iydy2-hoYqGDSWqd9WCTUXh214O-uCc3nVNiVA@mail.gmail.com>
	<50059AF8.5050805@sugarcrm.com>
	<CAEZPtU4hQ5GjMZ2b6T5d1_dTp01r7_rg8613JZ_5AuBVc29B7w@mail.gmail.com>
	<5005CB58.2020601@sugarcrm.com>
	<CAEZPtU6as2QKQKfp6cCrW=Xjq9v3ZW1u+jbNJBT0DfDQoa8CdA@mail.gmail.com>
	<50066724.6050901@sugarcrm.com>
	<CAEZPtU6hK8rZFA+QLT4vPch+QdZ9r4FgBsJAVcpaBWW7VFA1ow@mail.gmail.com>
	<50067040.3090307@sugarcrm.com>
	<CAEZPtU5=HFC=enGgNCLssFziOxViw5ekPv1e6Ky093rxOP5ZhQ@mail.gmail.com>
	<CAN+gjSfonNonHSBv4=9=VdVgP=OfvRQvLbshT1rxcZ83vrozYw@mail.gmail.com>
	<5006E5BB.50906@sugarcrm.com>
Date: Wed, 18 Jul 2012 18:45:30 +0200
Message-ID: <CAEZPtU7YVoLxfXc9jC=skfKb65C3uYQTXQr7-r2xu2nRETX3uA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Andrew Faulds <ajfweb@googlemail.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: pierre.php@gmail.com (Pierre Joye)

hi Stas,


On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> enough but I don't know the Zend engine well enough). This way we can
>> have array->key, array->sort(TYPE), etc. for new code to use, instead of
>> the legacy array and string method mess (the latter needs a cleanup more
>> in particular).
>
> The mess does not exist because we have array_key() instead of
> array->key(). There's nothing wrong with having array_key(). The mess
> exists because functions do not form single API with single principle
> behind it, but were added in ad-hoc manner, sometimes without
> correlating them with others. So, if you want to clean it up, you'd want
> to write a plan how new API would look like and how it will be better
> than old one. If the solution is "let's use ->" then it's not worth it.
> The solution that's worth it is "let's have this better API" and that's
> where we should start, not with changing array_key() to array->key() and
> saying "now we have clean sexy API".
>

Please let me refresh the psat years history of PHP releases. Any
attempt to change any kind of function signatures in the core has been
rejected for obvious reasons (BC breaks, useless code changes, etc.
etc.). So I won't spend a single second to try to propose to rewamp or
duplicate functions for the sake of making the signature more
consistent with each other, or cleaner.

On the hand, this solution allows that, right away, without BC breaks
and brings us to the (very) long term goal (actual object for standard
types, like in other languages).

Now you can totally disregard the benefit of this (purely vaporware
right now) solution, but to keep saying that this argument is
pointless is not going to bring us any step further, really not.


Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org