Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61408
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
Sender: amaury.bouchard@gmail.com
In-Reply-To: <CAN+gjSfonNonHSBv4=9=VdVgP=OfvRQvLbshT1rxcZ83vrozYw@mail.gmail.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>
Date: Wed, 18 Jul 2012 17:27:14 +0200
Message-ID: <CAPaKmRm-h=4PSiy4tRwzcvuUkeGv3bTNNVEHbz6Y6MnvbwzOGQ@mail.gmail.com>
To: Andrew Faulds <ajfweb@googlemail.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f83a7356c224a04c51c4d1c
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: amaury@amaury.net (Amaury Bouchard)

--e89a8f83a7356c224a04c51c4d1c
Content-Type: text/plain; charset=ISO-8859-1

Seems a lot like another syntactic sugar.

Like in Lua, where you can write
   obj:method(12)
instead of
   obj.method(obj, 12)

But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing array?) is a tough one.


2012/7/18 Andrew Faulds <ajfweb@googlemail.com>

> OK, ok. Let me clear some things up here.
>
> We don't want it to make things more object-oriented or whatever. The real
> motivation is to give us a chance to make a much cleaner, much nicer array
> API without breaking BC. We can keep the legacy array_* and unprefixed
> functions, but we can also create "pseudo-object methods" (not objects, but
> methods and possibly properties hooked into the method call processing,
> checking for non-object types - it's very easy to check (I've done it) for
> non-objects, and implementing this seems simple 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).
>
> OK?
> On Jul 18, 2012 10:14 AM, "Pierre Joye" <pierre.php@gmail.com> wrote:
>
> > hi,
> >
> > On Wed, Jul 18, 2012 at 10:13 AM, Stas Malyshev <smalyshev@sugarcrm.com>
> > wrote:
> >
> > > And no, it does not "allow us to clean our APIs" - I again point out
> > > using -> has nothing to do with cleaning APIs. Repeating "clean APIs"
> > > as if it is some magic spell will not make false statement true, and
> the
> > > statement that using -> somehow cleans up APIs is false. Cleaning APIs
> > > and pseudo-objects are two completely different things, and nobody yet
> > > shown any relationship between the two.
> >
> > You do not see it, your call. But it indeed does and anyone I was
> > talking to about this topic agrees with this view but two persons (you
> > incl.).
> >
> > Anyway, it is somehow pointless to argue to death about that as it is
> > technically not possible yet. I'm 200% sure it will happen.
> >
> > Cheers,
> > --
> > Pierre
> >
> > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

--e89a8f83a7356c224a04c51c4d1c--