Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61517
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.213.42 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAN+gjSe7r2SoRNYufcaB2ktK05shH1AcAsaFSbUibF9r4TeRrw@mail.gmail.com>
References: <CAN+gjSe7r2SoRNYufcaB2ktK05shH1AcAsaFSbUibF9r4TeRrw@mail.gmail.com>
Date: Thu, 19 Jul 2012 13:52:43 -0700
Message-ID: <CAESVnVrJ5rvB7JhrZ7wBBAwFn2+QouGd2gF5Tn4Er-2XSfLZMQ@mail.gmail.com>
To: Andrew Faulds <ajfweb@googlemail.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f3b9c110c8a0004c534f639
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: pollita@php.net (Sara Golemon)

--e89a8f3b9c110c8a0004c534f639
Content-Type: text/plain; charset=ISO-8859-1

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

--e89a8f3b9c110c8a0004c534f639--