RE: [PECL-DEV] String extension proposal

The PHP RFC wiki is at http://wiki.php.net/rfc. Iterator can probably allow a lot of things, especially on arrays, but SPL in general is so poorly documented that I prefer not to use it. I may be wrong as it probably contains a lot of valuable features but I am very strict on the documentation and I expect from others the same I provide with the software I release. There is another point: if we implement a smart use of return_value_used, allowing in-place transformations when the return value is not used, there are cases where a string becomes an array (as explode) or the opposite (as implode). If we write real classes, it is possible only if both types belong to the same class. I worked on the subject today and I think of a wrapper mechanism in the executor which will accept an OO syntax for native types, map these 'pseudo'-methods to function calls, rearrange the arguments, call the corresponding function, and manage in-place modifications according to the return_value_used flag. At init time, the extensions would register the OO mappings they want. This would allow to define an OO alternative syntax for any type, including resources. There wouldn't be any 'real' class, which is a drawback as there could be no class extension nor reflection, nor any class/object specific feature, but it allows to support a syntax many people would appreciate, with minimal performance overhead and minimal modifications in the code. Not sure if this can be implemented without core modifications but this is best solution I've found so far. Tomorrow, I will work on the executor again, which is not a piece of cake. If somebody with parser/executor knowledge wants to help, he's welcome. Last point : Shouldn't this thread be moved to the 'internals' ML, even if it could start a flame war ;) ? Regards Francois > -----Message d'origine----- > De : Mark Frawley [mailto:markfrawley@gmail.com] > Envoyé : jeudi 12 juin 2008 10:05 > À : flconseil@yahoo.fr > Cc : pecl-dev@lists.php.net; joe@joestump.net > Objet : Re: [PECL-DEV] String extension proposal > > > Hi Francois, > Can you send me on that link to the RFC wiki? Also I agree it would > get confusing having two types of string. > Wouldn't implementing Iterator allow one to do a foreach on the Array > object? Is there any way I can help out with this? > > Regards, > Mark > > On Wed, Jun 11, 2008 at 11:49 PM, Francois Laupretre > <flconseil@yahoo.fr> wrote: > > The only thing I am sure about OO strings/arrays is that we cannot have > > separate 'native' strings and 'object' strings, even if it is easier > > to > > implement (and __tostring() cannot work for arrays). It also > would probably > > have a significant impact on performances. > > > > The idea I want to investigate is a wrapper to allow method > calls on native > > types. Each method would call the corresponding function. If it > works, the > > next step will be to use return_value_used to modify variables > in place if > > the result is not used. Then, there will be some other points > to consider, > > as the possibility to extend these classes, reflection, calling > methods on > > immediate values,... > > > > Joe : I don't understand why you talk about BC breaks, as the > approach I am > > taking does not break any BC, it is just an extension to the > current syntax. > > Or did I miss something ? > > > > I have also started an RFC detailing the methods, type by type. > When it is > > ready, I'll try to publish it on the RFC wiki. > > > > Regards > > > > François > > > >> De : Mark Frawley [mailto:markfrawley@gmail.com] > >> > >> The more I think about it the more I like Francois' idea. The idea of > >> making them separate is appealing only because it is more realistic. > >> I really do believe it is a really good direction for PHP. I haven't > >> heard a good argument against it. > >> Could someone who is in a decision making capacity find the time to > >> address this request? I know it might be tedious to revisit it, > >> but it does seem I'm not the only programmer looking for this feature. > >> > >> Regards, > >> Mark > >> > >> On Tue, Jun 10, 2008 at 9:38 PM, Francois Laupretre > >> <flconseil@yahoo.fr> wrote: > >> >> De : Joe Stump [mailto:joe@joestump.net] > >> >> > >> >> as a smart man once said, "I disapprove of what you say > >> >> (code), but I will defend to the death your right to say > (code) it." ;) > >> > > >> > +1 > >> > > >> >> I for one would love a unified OO interface for both strings and > >> >> arrays as I find them to be more concise. A good example of what I'm > >> >> looking for would be: > >> >> > >> >> $arr = new array('foo'); > >> >> $foo = $arr->pop(); > >> > > >> > Defining String & Array classes is interesting but it would be > >> much better > >> > if these objects could remain compatible with native strings > and arrays. > >> > > >> > Combining this with a smart use of return_value_used, it would give > >> > something like : > >> > > >> > $arr=array(' FOO ','bar'); > >> > > >> > $a2=$arr->reverse(); // $arr is not modified, The > reversed array is > >> > returned. > >> > > >> > $arr->reverse(); // $arr is reversed in place > >> > > >> > $s=$arr->pop(); // returns ' FOO ' > >> > > >> > $s2=$s->trim()->tolower(); // returns 'foo' > >> > > >> > $s->trim(); // $s becomes 'FOO' > >> > > >> > I know it cannot be done as an extension to the current core > >> and implies a > >> > mechanism allowing to consider native types as objects (at > least to call > >> > methods). > >> > > >> > Please don't reply that it's too complex ot that I'd rather use > >> > python/java/cobol(just kidding)... > >> > > >> > Regards > >> > > >> > Francois > >> > > >> > > >> > >> -- > >> PECL development discussion Mailing List (http://pecl.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > > >