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 \nume
On Apr 2, 2011, at 15:24 , Jordi Boggiano wrote:
> 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
On Sat, Apr 2, 2011 at 12:41 PM, Stan Vass wrote:
> 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 b
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. Anyb
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) ===
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 = 'string';
>>> $s1->contai
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);
>>
>>
> string substr( string $string, int $start [, int $second [, int $flag =
> SUBSTR_LENGTH ]])
I think this just makes code ugly.
I think a new function with something like 'slice' in it is pretty unambiguous and
unconfusing.
(I also like the current substr() semantics. Actually, I think 'slic
On 31 March 2011 17:50, Philip Olson wrote:
>
> On Mar 31, 2011, at 9:55 AM, Sebastian Bergmann wrote:
>
>> Am 31.03.2011 17:52, schrieb Rasmus Lerdorf:
>>> Argh! Everyone should be forced to learn a bit of C. Like many PHP
>>> functions, the name and argument order is right out of libc. If you ty
Hi all,
I just come back on the first reflexion about adding a str_slice()
function. As it
says before, using one method or the orther can really sucks in some
cases, depending
what you are coding about.
So actually you mention there is two possibility :
- Keep all in the actual state. substr
On a somewhat related note (and going back a little to my original patch),
languages like python and ruby allow slicing on array/string objects with
$string_or_array[start:end] syntax. I think this would be really useful
syntax in PHP as well (and would of course make the initial patch I
submitted
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
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 o
On Mar 31, 2011, at 9:55 AM, Sebastian Bergmann wrote:
> Am 31.03.2011 17:52, schrieb Rasmus Lerdorf:
>> Argh! Everyone should be forced to learn a bit of C. Like many PHP
>> functions, the name and argument order is right out of libc. If you type
>> "man strstr" at your (non-Windows) prompt you
On 31 March 2011 16:43, Brian Moon wrote:
>>> How would str_contains() be different from strstr()?
>>>
>>>
>> They differ in the return type
>
> $instr = (bool)strstr($string1, $string2);
>
> done. No need for a new function.
God forbid anyone use (bool)strstr("something0", "0") !
>
> Brian.
>
>
Am 31.03.2011 17:52, schrieb Rasmus Lerdorf:
> Argh! Everyone should be forced to learn a bit of C. Like many PHP
> functions, the name and argument order is right out of libc. If you type
> "man strstr" at your (non-Windows) prompt you get a nice little
> description of what it does.
And if you
On 03/31/2011 08:45 AM, Philip Olson wrote:
> - Intuitive name
Argh! Everyone should be forced to learn a bit of C. Like many PHP
functions, the name and argument order is right out of libc. If you type
"man strstr" at your (non-Windows) prompt you get a nice little
description of what it does.
On Mar 31, 2011, at 9:43 AM, Brian Moon wrote:
>>> How would str_contains() be different from strstr()?
>>>
>>>
>> They differ in the return type
>
> $instr = (bool)strstr($string1, $string2);
>
> done. No need for a new function.
Well, to be clearer:
bool str_contains( haystack, needle [,
On 31.03.11 17:05, Rasmus Lerdorf wrote:
> On 03/31/2011 07:41 AM, Philip Olson wrote:
>> On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote:
>>> I recently got around to merge them into a largely unfinished extension
>>> so they are archived somewhere safe: https://github.com/mj/php-ext-str
>>
>> I
How would str_contains() be different from strstr()?
They differ in the return type
$instr = (bool)strstr($string1, $string2);
done. No need for a new function.
Brian.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Martin Scotta
On Thu, Mar 31, 2011 at 12:05 PM, Rasmus Lerdorf wrote:
> On 03/31/2011 07:41 AM, Philip Olson wrote:
> >
> > On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote:
> >
> >> On 30.03.11 21:36, Dan Birken wrote:
> >>> As for adding other string functions, I agree, I think there are a l
On 03/31/2011 07:41 AM, Philip Olson wrote:
>
> On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote:
>
>> On 30.03.11 21:36, Dan Birken wrote:
>>> As for adding other string functions, I agree, I think there are a lot of
>>> them that would be great to add. starts_with & ends_with for sure.
>>
>> B
On Thu, Mar 31, 2011 at 4:49 PM, Martin Jansen wrote:
> On 31.03.11 16:41, Philip Olson wrote:
> > On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote:
> >> Both str_startswith and str_endswith have been suggested in the past:
> >>
> >> http://marc.info/?t=12164723011&r=1&w=2
> >>
> >> I recentl
On 31.03.11 16:41, Philip Olson wrote:
> On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote:
>> Both str_startswith and str_endswith have been suggested in the past:
>>
>> http://marc.info/?t=12164723011&r=1&w=2
>>
>> I recently got around to merge them into a largely unfinished extension
>> so t
On Mar 30, 2011, at 1:42 PM, Martin Jansen wrote:
> On 30.03.11 21:36, Dan Birken wrote:
>> As for adding other string functions, I agree, I think there are a lot of
>> them that would be great to add. starts_with & ends_with for sure.
>
> Both str_startswith and str_endswith have been suggeste
I think most users of a language take what they are given for basic
functions like this instead of always rolling their own. I admit that both
of the changes I am suggesting here are minor, but taken together I do think
it is a significant and tangible difference (and improvement). I think if
you
If substr() really was so bad, then surely we'd see userland
implementations of str_slice() in every project?
Jevon
On Wed, Mar 30, 2011 at 7:06 PM, Dan Birken wrote:
> My apologizes if I am bringing up a topic that has been discussed before,
> this is my first time wading into the PHP developer
On 30.03.11 21:36, Dan Birken wrote:
> As for adding other string functions, I agree, I think there are a lot of
> them that would be great to add. starts_with & ends_with for sure.
Both str_startswith and str_endswith have been suggested in the past:
http://marc.info/?t=12164723011&r=1&w=2
The example I picked in my patch was a little contrived, however I do think
it is a useful benefit for functions to work in ways people expect, even in
edge cases. There are a lot of people out there who do not know the
difference between == and ===, and I think the fact that str_slice() has one
l
Am 30.03.2011 17:54, schrieb Chad Fulton:
> While I personally like PHP's substr() an awful lot
>
> With that in mind, if this function was to be implemented, I think
> that naming it substring() instead of str_slice() might make it easier
> for people to pick up out of the box, since PHP develop
Hello!
While I personally like PHP's substr() an awful lot and doubt I would
use the str_slice() method, I thought I'd mention that I think what
you're proposing is much like the string.substring(from, to) method in
Javascript (and PHP's current substr() function is an awful lot like
Javascript's
On Wed Mar 30 09:05 AM, Hannes Landeholm wrote:
>
> var_dump(\substr("foo", 5, 6) == "", (string) false, false == "");
>
> Welcome to PHP. To be honest this criticism pretty much falls in the
> "from person that comes from another language X and is annoyed that
> every little detail isn't exact
"This thread shouldn't be a criticism of substr(), it would be
pointless. Its signature and behaviour will never change, unless
perhaps around April 1st as a practical joke on the millions of
websites it would break."
That's a really good joke actually. I can imagine how angry people would
get. Ma
On 30 March 2011 15:05, Hannes Landeholm wrote:
> Parsing is a problem in many real-world
> problems and substr currently works great for that purpose.
That's funny because the first thing I thought when I read the
original mail was "oh that would be great for parsing." In fact, I've
just grep'ed
IMHO substr is just fine enough. It does what you expect and behaves great
on edges cases.
What I believe is that we need more high-level string abstractions (and that
includes functions as well)
substr, strpos and the like works just fine to access strings by offsets,
but when you need to work wi
PHP's substr() is awesome and that comes from a person that code in at least
5 different languages daily. Parsing is a problem in many real-world
problems and substr currently works great for that purpose. You work with
two parameters: offset and length of parsing. Since meaning of a negative
offse
I think when the values are positive everything is mostly great. I think
when the values are negative is where the main problems are. Both the C
function strncpy() and the C++ strings substr() function only support
positive values for length AFAIK.
I just think it is very unintuitive for the fir
I just love substr() and I think all other languages got it wrong;)
Seriously...it behaves the same as implementations in other languages as
long as values are positive, right? how is that counter-intuitive? How
do other languages handle negative values?
Am 30.03.2011 08:06, schrieb Dan Birke
My apologizes if I am bringing up a topic that has been discussed before,
this is my first time wading into the PHP developers lists and I couldn't
find anything particularly relevant with the search.
Here is a bug I submitted over the weekend (
http://bugs.php.net/bug.php?id=54387) with an attach
39 matches
Mail list logo
