Re: Re: String extension proposal

From: Date: Wed, 11 Jun 2008 17:46:36 +0000
Subject: Re: Re: String extension proposal
References: 1 2  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-5503@lists.php.net to get a copy of this message
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 > >

« previous php.pecl.dev (#5503) next »