Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51791
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain oettinger.dk from 209.85.161.42 cause and error)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <4D94C380.2070402@lerdorf.com>
Date: Sat, 2 Apr 2011 14:38:10 +0300
Cc: Martin Scotta <martinscotta@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <7277ABA7-4B48-49FC-8974-512D4341CCC9@oettinger.dk>
References: <AANLkTinWgyueX7FJKdHASzOV0X0L480jnjd=o=mrG2kZ@mail.gmail.com>	<4D92CC38.5040900@toolpark.com>	<AANLkTimpmjOQcqLcfH23Zrt6EULw6PAJvQ1_cvAP7ON=@mail.gmail.com>	<AANLkTinp1wnOu6te6MjoONcz_1AVobc7pwFwvbY8mkTB@mail.gmail.com>	<004301cbeee8$e54a8280$afdf8780$@com>	<AANLkTi=MTU=AM-FeX1ZbTrrEDdNCPWNvcppWrxxbWGcg@mail.gmail.com>	<4D9387BE.4030808@divbyzero.net>	<E6786318-197A-4C8A-AAE2-A24DADDA7BA2@roshambo.org>	<4D94984D.8060700@lerdorf.com>	<AANLkTi=j1z8f8bO10Z9yENEN9NTPkt3Y7nBPDngkSLFi@mail.gmail.com>	<4D94A111.7050501@moonspot.net>	<520FB834-2614-4873-AC3B-0B2594B18471@roshambo.org>	<4D94A350.70201@lerdorf.com> <AANLkTinnvOy+gh-ZfJqf3SND3qFZ8ecntThfu2Yfo5Bm@mail.gmail.com> <4D94C380.2070402@lerdorf.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: jacob@oettinger.dk (Jacob Oettinger)

On Mar 31, 2011, at 21:10 , Rasmus Lerdorf wrote:

> On 03/31/2011 10:58 AM, Martin Scotta wrote:
>> I think it's time to stop thinking in terms of "functions" and move
>> forward to "abstractions"
>>=20
>> $s1 =3D 'string';
>> $s1->contains($s2);=20
>>=20
>> $s1->indexOf($s2) =3D=3D=3D strpos($s1, $s2);
>>=20
>> Why can't the strings be exposed as pseudo-objects ? users can choose =
to
>> use them as a regular strings or by calling methods on it.
>=20
> This is actually something I have been toying with a bit. Adding the
> ability to call methods on both strings and arrays. I still don't like
> the idea of making them real objects as the overhead and the amount of
> code that would need to be changed in the core and in every extension =
is
> daunting. Anybody out there have a patch along these lines?


Sounds interesting. A few thoughts:

The new "methods" could be implemented as functions that accept the =
string or array as their first argument. Thereby allowing them to be =
called as functions too.

If the new methods are functions. Maybe they should be defined in the =
\string and \array namespaces. This would allow a fresh start in naming =
string and array functions, and allow addressing argument ordering =
issues. It would of curse also open endless discussions on which =
functions to include and the naming of these.

If the new string and array functions were defined in some namespaces. =
Would it be possible to allow extending the string and array "classes" =
by defining more functions in those namespaces in userland and/or =
extensions?

Should the new string functions be multibyte character set aware?

Should the above be generalized so that the -> operator can be used on =
any simple type, and if the called "method" exists as a function in the =
types namespace, it should be called. This would break the task into two =
parts. !) changing php to attempt calling functions in a certain =
namespace for each simple type. 2) Writing extensions that create =
functions for each type, string and/or array would be obvious starting =
points.=20=