Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51793
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=lQKPBFEDwE6IWqWKMYyesDzRSnwRj8xHwyHhtB54POG/BSTQV5S6xmGG/aCdAge93V
         Hu1S0orK6xpVGOHv4GJH2qbc6Hprh7VRf32lO9fC72eUnmqoJFSzosNi3bS+4SIsnUDk
         qct8F9mhgGLF6QY3loJFTgZVoQk7B/tgb66mQ=
Message-ID: <4D971A32.6040106@gmail.com>
Date: Sat, 02 Apr 2011 14:44:34 +0200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16pre) Gecko/20110319 Lightning/1.0b2 Lanikai/3.1.10pre
MIME-Version: 1.0
To: PHP Development <internals@lists.php.net>
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>
In-Reply-To: <7277ABA7-4B48-49FC-8974-512D4341CCC9@oettinger.dk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Adding a more logical string slicing function to PHP
From: pasthelod@gmail.com (Pas)

On 2011.04.02. 13:38, 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 = 'string';
>>> $s1->contains($s2);
>>>
>>> $s1->indexOf($s2) === strpos($s1, $s2);
>>>
>>> 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.
>>
>> 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.

If I'm not mistaken you're talking about something like the Extension 
Methods in C#  ( http://msdn.microsoft.com/en-us/library/bb383977.aspx ) 
which, by the way, seems like a great idea.

The other thing that comes to mind is Scala's implicits ( 
http://www.codecommit.com/blog/ruby/implicit-conversions-more-powerful-than-dynamic-typing 
) It solves the same problem, while being really powerful, because of 
Scala's type system.


The problem of conflicting implicits (or whatever it'll be called) of 
course should be left to the developer, much like aliasing for traits.


-- 
Pas