Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVrJ5rvB7JhrZ7wBBAwFn2+QouGd2gF5Tn4Er-2XSfLZMQ@mail.gmail.com>
References: <CAN+gjSe7r2SoRNYufcaB2ktK05shH1AcAsaFSbUibF9r4TeRrw@mail.gmail.com>
	<CAESVnVrJ5rvB7JhrZ7wBBAwFn2+QouGd2gF5Tn4Er-2XSfLZMQ@mail.gmail.com>
Date: Thu, 19 Jul 2012 22:42:03 +0100
Message-ID: <CAN+gjSfKzWCe3W4BZFnPZpD8=VUjnTYrp=KKcO2+9L-Onjwybw@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e0cb4efa789a7989f404c535a6d9
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: ajfweb@googlemail.com (Andrew Faulds)

--e0cb4efa789a7989f404c535a6d9
Content-Type: text/plain; charset=UTF-8

I never said treat them as objects. I said give them methods. Not the same
thing.

And what do you mean by "technical debt"?
On Jul 19, 2012 9:52 PM, "Sara Golemon" <pollita@php.net> wrote:

>
>
> On Mon, Jul 16, 2012 at 4:27 PM, Andrew Faulds <ajfweb@googlemail.com>wrote:
>
>> I think PHP could benefit from making arrays, strings, integers,
>> floats, and possibly booleans, into "pseudo-objects". By this I mean
>> that they are not really objects (they are still primitive types and
>> keep their passing semantics), but they have methods. For instance,
>> instead of array_keys($array), one could do $array->keys();
>
>
> How about just creating (in PEAR or PECL) a Php Type Library which lets
> you write all the new code you want which treats all these things in a
> Javaish OOP way, but leave PHP's functional roots alone?
>
> $str = new String("Foo");
> if (3 == $str->length()) echo $str->toUpper();
>
> I think automagically treating actual non-objects as objects is just
> asking for massive amounts of confusion.  The technical debt PHP would take
> on from doing something like this would be... painful.
>
> If you *really* feel strongly about it, then I'd suggest you grab
> pecl/operator as a starting point and create an extension which hooks the
> opcodes involved in method calls to route to scalar handlers instead of
> producing the error message which they do now.  If you want to get clever,
> you might even make the prototype classes for the scalar handlers
> extensible to override functionality in userspace, but don't tell anyone I
> suggested that. :)
>
> -Sara
>

--e0cb4efa789a7989f404c535a6d9--