Last call: any more objections?
Moriyoshi
On Thu, Feb 19, 2009 at 11:52 AM, Moriyoshi Koizumi wrote:
> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski
> wrote:
>> Moriyoshi Koizumi wrote:
>>>
>>> As I said earlier, the function is never supposed to be used with
>>> objects. Therefore, we cann
On Thu, Feb 19, 2009 at 3:14 PM, Ian Eure wrote:
> On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote:
>
>> On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski
>> wrote:
>>>
>>> Moriyoshi Koizumi wrote:
As I said earlier, the function is never supposed to be used with
objects. There
On Feb 18, 2009, at 6:52 PM, Moriyoshi Koizumi wrote:
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski > wrote:
Moriyoshi Koizumi wrote:
As I said earlier, the function is never supposed to be used with
objects. Therefore, we cannot declare it to be broken, and any
change
to the behavior an
On Thu, Feb 19, 2009 at 4:51 AM, Andrei Zmievski wrote:
> Moriyoshi Koizumi wrote:
>>
>> As I said earlier, the function is never supposed to be used with
>> objects. Therefore, we cannot declare it to be broken, and any change
>> to the behavior anyway leads to a huge BC break. I got a report tha
Yes, those should be fixed too, but it's more difficult to do because they accept varargs,
so not clear where the flag should go.
-Andrei
Moriyoshi Koizumi wrote:
In addition, we should look at similar comparison-involved array
functions such as array_intersect, array_diff and so on, otherwise
Moriyoshi Koizumi wrote:
As I said earlier, the function is never supposed to be used with
objects. Therefore, we cannot declare it to be broken, and any change
to the behavior anyway leads to a huge BC break. I got a report that
claims the reporter's real-world application behaves strangely with
In addition, we should look at similar comparison-involved array
functions such as array_intersect, array_diff and so on, otherwise
it's gonna be a mess.
Moriyoshi
On Wed, Feb 18, 2009 at 11:43 AM, Moriyoshi Koizumi wrote:
> On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski
> wrote:
>
>> SORT_S
On Wed, Feb 18, 2009 at 3:11 AM, Andrei Zmievski wrote:
> SORT_STRING can only reliably deal with strings - its behavior on non-string
> type is basically broken. Unless we agree that PHP is Tcl (strings are the
> only type), then SORT_REGULAR makes much more sense to me, and evidently
> others.
Moriyoshi Koizumi wrote:
Ilia Alshanetsky wrote:
I've discussed this issue with Andrei at least a month ago (if not
longer) when the patch was originally added, and I believe that the
introduced behavior is the correct one.
IMO correct or not depends on the context where the function is used.
Anyone's thoughts on this?
I'm thinking of re-reverting in 48 hours without further objections.
Moriyoshi
On Sun, Feb 15, 2009 at 11:48 PM, Moriyoshi Koizumi wrote:
> Ilia Alshanetsky wrote:
>> I've discussed this issue with Andrei at least a month ago (if not
>> longer) when the patch was orig
Ilia Alshanetsky wrote:
> I've discussed this issue with Andrei at least a month ago (if not
> longer) when the patch was originally added, and I believe that the
> introduced behavior is the correct one.
IMO correct or not depends on the context where the function is used.
At least, as array_uni
I understand the illusion part. With foreach() I can see the gain and how
it improves readability and the code. But with count() I just don't see it.
Maybe because the foreach() alternative is not only $obj->foreach() but
something much uglier :)
So yeah, I think there's quite a substantial dif
Andi Gutmans wrote:
Why can't people who implement the Countable interface use $obj->count()
instead of count($obj)?
I guess the idea of SPL is hide the difference between real arrays and
some homebrewed containers. The question is how much you want to
maintain this illusion, i.e. what operation
I guess I'm missing something basic.
Why can't people who implement the Countable interface use $obj->count()
instead of count($obj)?
I just don't see any reason to overload count() in this scenario. It does
set a precendent to overload all of array.c and as I mention, there is no
reason why cou
Hello Andrey,
Saturday, November 20, 2004, 5:49:46 PM, you wrote:
> Marcus Boerger wrote:
>> Hello Christian,
>>
> ...
>> - __serialize(), __unserialize() controlled by a provided implementation
>> and handled by ext/standard
> ...
>>
>> Best regards,
>> Marcusmai
Marcus Boerger wrote:
Hello Christian,
...
- __serialize(), __unserialize() controlled by a provided implementation
and handled by ext/standard
...
Best regards,
Marcusmailto:[EMAIL PROTECTED]
You mean __sleep() and __wakeup() or?
Thanks,
Andrey
--
PHP Internals - PH
Marcus Boerger wrote:
Mabe you should look here at the engine description in Zend directory of
you PHP source.
Ok, thanks for you summary. I read that and had a look at ZEND_CHANGES.
- [] is overloaded by interface ArrayAccess (this is engine level only
count() is missing here)
- count() is overl
Hello Christian,
Saturday, November 20, 2004, 2:59:07 PM, you wrote:
> Marcus Boerger wrote:
>> We already decided not to allow ArrayAccess implementations to work
> Ok, excuse my ignorance, so what's the list of functions/constructs
> affected by SPL?
> - foreach
> - []
> - count()
> What el
Marcus Boerger wrote:
We already decided not to allow ArrayAccess implementations to work
Ok, excuse my ignorance, so what's the list of functions/constructs
affected by SPL?
- foreach
- []
- count()
What else? Are there plan to extend that at a later stage? [ Simply
point me to an online docume
Hello Dirkjan,
Saturday, November 20, 2004, 1:01:22 PM, you wrote:
> If it works in count(), will it work in sizeof() as well?
See: http://php.net/sizeof
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
Hello Christian,
Saturday, November 20, 2004, 11:47:01 AM, you wrote:
> Marcus Boerger wrote:
>> We don't do this for any other interface based 'magic' (iterators, array
>> overloading). But if that's your only concern then i'll happily change
> I think the keyword here is 'magic'. This introduc
If it works in count(), will it work in sizeof() as well?
Regards,
Manuzhai
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marcus Boerger wrote:
We don't do this for any other interface based 'magic' (iterators, array
overloading). But if that's your only concern then i'll happily change
I think the keyword here is 'magic'. This introduces another mechanism
for overloaded behaviour.
Something can now
a) implement an
Hello Andi,
Saturday, November 20, 2004, 1:02:05 AM, you wrote:
> At 10:26 AM 11/19/2004 +0100, Marcus Boerger wrote:
>>You simply implement the interface countable and then your objects can be
>>put into count() to get the count function called. This is very helpful
>>with ArrayObject/ArrayItera
At 10:26 AM 11/19/2004 +0100, Marcus Boerger wrote:
You simply implement the interface countable and then your objects can be
put into count() to get the count function called. This is very helpful
with ArrayObject/ArrayIterator which are array wrappers and thus they
should work in count() as expec
Hello Andi,
Friday, November 19, 2004, 12:09:12 AM, you wrote:
> At 08:55 AM 11/17/2004 +0100, Marcus Boerger wrote:
>>Hello Andi,
>>
>>Tuesday, November 16, 2004, 11:56:48 PM, you wrote:
>>
>> > Marcus,
>>
>> > I didn't see discussion about this. How much is such a countable interface
>> > reall
At 08:55 AM 11/17/2004 +0100, Marcus Boerger wrote:
Hello Andi,
Tuesday, November 16, 2004, 11:56:48 PM, you wrote:
> Marcus,
> I didn't see discussion about this. How much is such a countable interface
> really needed? Is this only for SPL or is this supposed to be general
> purpose. I would prefe
Hello l0t3k,
Wednesday, November 17, 2004, 2:08:26 PM, you wrote:
> Since we're kinda on the topic, i'd like to raise the issue of the status of
> SPL. i.e. will it be bundled standard ? i'm asking because alot of the work
> that was done in SPL should IMHO be core (e.g. the base exception classe
Since we're kinda on the topic, i'd like to raise the issue of the status of
SPL. i.e. will it be bundled standard ? i'm asking because alot of the work
that was done in SPL should IMHO be core (e.g. the base exception classes).
i'm wrapping a semi-large framework and i'd prefer not to redefine tho
Hello Andi,
Tuesday, November 16, 2004, 11:56:48 PM, you wrote:
> Marcus,
> I didn't see discussion about this. How much is such a countable interface
> really needed? Is this only for SPL or is this supposed to be general
> purpose. I would prefer to only see it in SPL but I see you made some
Marcus,
I didn't see discussion about this. How much is such a countable interface
really needed? Is this only for SPL or is this supposed to be general
purpose. I would prefer to only see it in SPL but I see you made some
changes to array.c. This might lead to inconsistency with the rest of PHP
Wez Furlong wrote:
> Should these functions really go into the core?
> Perhaps they are better off in an extension (pecl/array_utils ?)
>
> The names aren't really all that obvious to me either.
>
> --Wez.
Hi Wez,
well maybe array_udiff_uassoc() and array_diff_uassoc() are of little
need but I add
32 matches
Mail list logo
