Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51792 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77819 invoked from network); 2 Apr 2011 12:25:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Apr 2011 12:25:00 -0000 Authentication-Results: pb1.pair.com header.from=j.boggiano@seld.be; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=j.boggiano@seld.be; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain seld.be designates 209.85.214.42 as permitted sender) X-PHP-List-Original-Sender: j.boggiano@seld.be X-Host-Fingerprint: 209.85.214.42 mail-bw0-f42.google.com Received: from [209.85.214.42] ([209.85.214.42:40941] helo=mail-bw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B9/C7-09874-995179D4 for ; Sat, 02 Apr 2011 07:24:59 -0500 Received: by bwz18 with SMTP id 18so3215443bwz.29 for ; Sat, 02 Apr 2011 05:24:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.37.2 with SMTP id tc2mr4701697bkb.14.1301747094005; Sat, 02 Apr 2011 05:24:54 -0700 (PDT) Received: by 10.204.62.207 with HTTP; Sat, 2 Apr 2011 05:24:53 -0700 (PDT) In-Reply-To: <7277ABA7-4B48-49FC-8974-512D4341CCC9@oettinger.dk> References: <4D92CC38.5040900@toolpark.com> <004301cbeee8$e54a8280$afdf8780$@com> <4D9387BE.4030808@divbyzero.net> <4D94984D.8060700@lerdorf.com> <4D94A111.7050501@moonspot.net> <520FB834-2614-4873-AC3B-0B2594B18471@roshambo.org> <4D94A350.70201@lerdorf.com> <4D94C380.2070402@lerdorf.com> <7277ABA7-4B48-49FC-8974-512D4341CCC9@oettinger.dk> Date: Sat, 2 Apr 2011 14:24:53 +0200 Message-ID: To: Jacob Oettinger Cc: Rasmus Lerdorf , Martin Scotta , internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP From: j.boggiano@seld.be (Jordi Boggiano) On Sat, Apr 2, 2011 at 1:38 PM, Jacob Oettinger wrote: > 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" >>> >>> $s1 =3D 'string'; >>> $s1->contains($s2); >>> >>> $s1->indexOf($s2) =3D=3D=3D strpos($s1, $s2); >>> >>> Why can't the strings be exposed as pseudo-objects ? users can choose t= o >>> use them as a regular strings or by calling methods on it. >> >> 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 strin= g or array as their first argument. Thereby allowing them to be called as f= unctions too. > > If the new methods are functions. Maybe they should be defined in the \st= ring and \array namespaces. This would allow a fresh start in naming string= and array functions, and allow addressing argument ordering issues. It wou= ld 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. Wo= uld it be possible to allow extending the string and array "classes" by def= ining 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 an= y 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 eac= h simple type. 2) Writing extensions that create functions for each type, s= tring and/or array would be obvious starting points. 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. 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. Anyway, I hope this helps, my point is just that you shouldn't forget to check out how other languages solved the issue before hitting the wall ourselves. Not saying we have to do it all like JS, but they have something that works, so it's worth studying. Cheers [1] https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Nu= mber#Methods --=20 Jordi Boggiano @seldaek :: http://seld.be/