Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51796
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: <BANLkTinfVNXpBd5qXPi3Ry=w+zvojUxz4A@mail.gmail.com>
Date: Sat, 2 Apr 2011 20:32:41 +0300
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>,
 Martin Scotta <martinscotta@gmail.com>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <B79E141A-56B0-477B-A22B-D17806778A66@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> <7277ABA7-4B48-49FC-8974-512D4341CCC9@oettinger.dk> <BANLkTinfVNXpBd5qXPi3Ry=w+zvojUxz4A@mail.gmail.com>
To: Jordi Boggiano <j.boggiano@seld.be>
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: jacob@oettinger.dk (Jacob Oettinger)


On Apr 2, 2011, at 15:24 , Jordi Boggiano wrote:
> On Sat, Apr 2, 2011 at 1:38 PM, Jacob Oettinger <jacob@oettinger.dk> =
wrote:
>> On Mar 31, 2011, at 21:10 , Rasmus Lerdorf wrote:
>>=20
>>> 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
>>>> $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?
>>=20
>>=20
>> Sounds interesting. A few thoughts:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> Should the new string functions be multibyte character set aware?
>>=20
>> 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
> This would be great - especially if it would provide multibyte (or
> only UTF-8 for all I care) support. Of course one potential pain point
> is numbers vs strings.

As Stan Vass points out the methods should probably be implemented for =
scalars and for arrays, and handling of types should be done in the same =
way as the existing string and number functions. So maybe only \scalar =
and \array. Alternatively scalars should look for methods in multiple =
namespaces to keep the function naming consistent.

>=20
> Looking at JavaScript which acts quite similarly to the proposed
> approach, the Number methods [1] are not many and not often useful,
> but still they exist. What happens if you do "3.3"->ceil() ? If ceil()
> exists only in \numeric, you could say autoconvert, but if it exists
> in both \string and \numeric we have a problem, so the only sensible
> way is to drop type juggling for those autoboxed objects imo. Which is
> also what JS does btw. If you have an ambiguous value on your hands,
> you should cast it (x.toString() or parseInt(x)) first and then call
> what you want to call on it. Another interesting to note is that JS
> doesn't allow method calls directly on numbers - 3.toPrecision(2) for
> example is a syntax error, you have to put it in a var first. I guess
> it's not a problem since you should just inline the value you want
> anyway, the Number methods don't do super fancy things.

Yes as I wrote the above I did realize that it has some resemblance to =
javascripts prototypal inheritance, so it is a good idea to look there =
for inspiration. But the above is not supposed to be a suggestion for =
introducing a new object model into PHP.=