On Fri, 2008-11-21 at 12:15 -0800, Stanislav Malyshev wrote:
> Attached is the patch that should restore BC for all those functions
> except sorts and array_unique/array_flip (these should be trivial too
> but I still thing their support for objects is just a bug). Please tell
> if you are using
Hi!
. end
. prev
. next
. reset
. current
. key
. array_key_exists
. array_unique
. array_flip
. array_walk_recursive
. array_walk
. uksort
. uasort
. usort
. natcasesort
. natsort
Attached is the patch that should restore BC for all those functions
except sorts and array_unique/array_flip (t
Hi!
As a PHP user who'd want to migrate to 5.3 sooner than later, and uses
those heavily, I'd rather not see BC breaks in a point release, even
though just like you I see some WTF-s in the old behaviour.
You heavily use natsort on objects? What for?
If natsort covered the entirety of this B
Hi!
As a PHP user who'd want to migrate to 5.3 sooner than later, and uses
those heavily, I'd rather not see BC breaks in a point release, even
though just like you I see some WTF-s in the old behaviour.
You heavily use natsort on objects? What for?
--
Stanislav Malyshev, Zend Software Archit
Hi!
Hmm, I really think we should simply maintain BC 100% but using the new
BC 100% makes little sense - why usort can accept object but sort can't?
And functions like next/prev are useless with many types of objects.
Especialy think this through for the next
bigger release (presumably PHP
Hmm, I really think we should simply maintain BC 100% but using the
new parameter parsing API and then really think this through for the
next bigger release (presumably PHP 6.0) and come up with a set of
interfaces for objects that allow them to more sensibly work with
functions.
FWIW, I
Hi!
I am just worried that we do not have enough time to really think this
through all the way. So in the end we might end up having to break BC
once more in PHP 6.0. Also its not like we are fixing these bugs because
users were submitting bug tickets about this (or have they?).
Well, some o
On 21.11.2008, at 09:54, Stanislav Malyshev wrote:
bigger release (presumably PHP 6.0) and come up with a set of
interfaces for objects that allow them to more sensibly work with
functions.
We already have set of interfaces. They aren't just used
consistently. And that's a bug. We should
Hi!
Hmm, I really think we should simply maintain BC 100% but using the new
BC 100% makes little sense - why usort can accept object but sort can't?
And functions like next/prev are useless with many types of objects.
Especialy think this through for the next
bigger release (presumably PHP
Hi,
Hmm, I really think we should simply maintain BC 100% but using the
new parameter parsing API and then really think this through for the
next bigger release (presumably PHP 6.0) and come up with a set of
interfaces for objects that allow them to more sensibly work with
functions.
re
On Thu, 2008-11-20 at 15:52 -0800, Stanislav Malyshev wrote:
> Hi!
>
> > . end
> > . prev
> > . next
> > . reset
> > . current
> > . key
>
> I think those should be more friendly with Iterators, but for other
> objects probably not much sense to allow it. In 5.2 they modify or use
> current has
Hi!
. end
. prev
. next
. reset
. current
. key
I think those should be more friendly with Iterators, but for other
objects probably not much sense to allow it. In 5.2 they modify or use
current hash pointer, but for objects that doesn't make too much sense.
. array_key_exists
Here it m
2008/11/17 Andrei Zmievski <[EMAIL PROTECTED]>:
> I meant '&' actually.
>
> -Andrei
>
Ok, patch updated. http://felipe.ath.cx/diff/array_bc.diff
Go go go?
The rest is to fix 25 (at least ext/standard/array/) tests failing like:
343+ Warning: current() expects parameter 1 to be array or object,
n
I meant '&' actually.
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Felipe Pena wrote:
So as suggested and wished, here is a patch that add a modifier '%' to
'a' in parameter parsing API, where it allows object that implements
ArrayAccess to be accept. Although it doesn't invoke any their methods,
i.e. just how it works nowdays.
A list of functions that allow ob
On 15.11.2008, at 20:17, Stanislav Malyshev wrote:
Hi!
So what if we for now stick with the BC fix?
However maybe for PHP 6.0 we should make a real effort to figure
out how objects are supposed to be handled in our PHP type
juggeling world.
Depends what you mean by BC fix. If you mean j
Hi!
So what if we for now stick with the BC fix?
However maybe for PHP 6.0 we should make a real effort to figure out how
objects are supposed to be handled in our PHP type juggeling world.
Depends what you mean by BC fix. If you mean just rolling these
functions back to using zval** and con
2008/11/15 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
>
> On 13.11.2008, at 19:19, Stanislav Malyshev wrote:
>
>> Hi!
>>
>>> Can anyone write up a summary of the situation and the options we have?
>>
>> Sure. A number of array functions in 5.2 accept arrays, but use HASH_OF to
>> extract array value, w
On 13.11.2008, at 19:19, Stanislav Malyshev wrote:
Hi!
Can anyone write up a summary of the situation and the options we
have?
Sure. A number of array functions in 5.2 accept arrays, but use
HASH_OF to extract array value, which means they automatically
accept objects if the object has
Hi!
This isn't the type of thing that I would naturally expect to find
broken in a .x release, so if we can preserve the old behaviour with
little to no penalty, I suggest we go for that.
I'm not sure we can while preserving new API - since old API gave much
more wiggle room to particular fu
Also cant we some how automate the BC break testing for this (aka
scan all functions that accept an array with the old API in 5.2,
pass it an ArrayObject instance and see what happens and compare
that to 5.3)?
Yes we can ;) That should be not hard to do by looking at ones
having 'a' in pa
Hi!
Can anyone write up a summary of the situation and the options we have?
Sure. A number of array functions in 5.2 accept arrays, but use HASH_OF
to extract array value, which means they automatically accept objects if
the object has working get_properties handler. In 5.3, such function us
Hi,
Can anyone write up a summary of the situation and the options we have?
Also cant we some how automate the BC break testing for this (aka scan
all functions that accept an array with the old API in 5.2, pass it an
ArrayObject instance and see what happens and compare that to 5.3)?
rega
Hi!
a) I showed the 5.2 behavior, using "proper" interfaces is a silent
change which might break application and is probably hard to find. While
I don't know how many people rely on these "features".
I think it'd be OK for functions using HASH_OF in 5.2 keep using that,
and I'm not sure we sh
On Thu, 2008-11-06 at 23:21 +0200, Stan Vassilev | FM wrote:
> The exception should be made for any class implementing the relevant SPL
> interfaces, and that's not just ArrayObject.
>
> It may be seen as just "one class" but actually all of the "transparent"
> iterator implementations (for iter
On Thu, Nov 6, 2008 at 22:06, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-11-06 at 10:10 -0800, Stanislav Malyshev wrote:
>> Hi!
>>
>> > So as suggested and wished, here is a patch that add a modifier '%' to
>> > 'a' in parameter parsing API, where it allows object that implements
>
So allowing passing objects to array stuff using HASH_OF can lead to
unexpected behavior. Dropping the old behavior makes this clear ... but
is bad for stuff like ArrayObject.
I'm not sure whether we should add special rules for a single class
though ..
johannes
The exception should be made fo
On Thu, 2008-11-06 at 10:10 -0800, Stanislav Malyshev wrote:
> Hi!
>
> > So as suggested and wished, here is a patch that add a modifier '%' to
> > 'a' in parameter parsing API, where it allows object that implements
> > ArrayAccess to be accept. Although it doesn't invoke any their methods,
> > i
Em Qui, 2008-11-06 às 10:10 -0800, Stanislav Malyshev escreveu:
> Hi!
>
> > So as suggested and wished, here is a patch that add a modifier '%' to
> > 'a' in parameter parsing API, where it allows object that implements
> > ArrayAccess to be accept. Although it doesn't invoke any their methods,
>
Hi!
So as suggested and wished, here is a patch that add a modifier '%' to
'a' in parameter parsing API, where it allows object that implements
ArrayAccess to be accept. Although it doesn't invoke any their methods,
i.e. just how it works nowdays.
I think if you use HASH_OF then any object hav
So as suggested and wished, here is a patch that add a modifier '%' to
'a' in parameter parsing API, where it allows object that implements
ArrayAccess to be accept. Although it doesn't invoke any their
methods,
i.e. just how it works nowdays.
I applied this to HEAD and ran a few minor (manua
I applied this to HEAD
Oops. I mean to PHP_5_3 (keep forgetting that it's not HEAD).
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
Em Qua, 2008-11-05 às 16:20 +, Geoffrey Sneddon escreveu:
> On 4 Nov 2008, at 22:59, Stanislav Malyshev wrote:
>
> >> so where do we stand here?
> >
> > I'd prefer to have it fixed, but then it probably requires changing
> > the parameters API for 'a', which might lead to some unexp
On 4 Nov 2008, at 22:59, Stanislav Malyshev wrote:
so where do we stand here?
I'd prefer to have it fixed, but then it probably requires changing
the parameters API for 'a', which might lead to some unexpected
results with regard to functions that modify their arguments. I
think we may
I'd prefer to have it fixed, but then it probably requires changing
the parameters API for 'a', which might lead to some unexpected
results with regard to functions that modify their arguments. I
think we may leave it alone for this alpha but try to resolve it for
5.3 release.
If my opini
Hi!
so where do we stand here?
I'd prefer to have it fixed, but then it probably requires changing the
parameters API for 'a', which might lead to some unexpected results with
regard to functions that modify their arguments. I think we may leave it
alone for this alpha but try to resolve it
On 28.10.2008, at 15:33, Stan Vassilev | FM wrote:
I would say "no" for 5.3. But for 6 it would be fantastic to have
all array-related
operations supporting ArrayAccess interface, where possible.
+1 for this.
Hi,
cu, Lars
Just making sure but: I think the BC break should be fixed. It's
Hi,
Thanks for your positive feedback about my idea and sorry for hijacking this
thread.
Although my C skills are limited to its syntax only I'll create an RFC, then
someone
else might give it a try an create a patch.
All the best,
Ionut
On Tue, Oct 28, 2008 at 4:23 PM, Kalle Sommer Nielsen
<[
2008/10/28 Stan Vassilev | FM <[EMAIL PROTECTED]>:
>> > class Test
>> {
>> public function hello($who)
>> {
>> echo 'Hello ' . $who;
>> }
>> }
>>
>> $closure = function()
>> {
>> static $instance;
>>
>> if(!$instance)
>> {
>> $instance = new Test;
>> }
>>
>> return($instance);
>> };
>>
>> $closure-
I would say "no" for 5.3. But for 6 it would be fantastic to have all
array-related
operations supporting ArrayAccess interface, where possible.
+1 for this.
Hi,
cu, Lars
Just making sure but: I think the BC break should be fixed. It's breaking
actual code out there. The practice of passing
Hi Ionut
2008/10/28 Ionut Gabriel Stan <[EMAIL PROTECTED]>:
> While we're at this and considering the new lambdas that we now have in the
> language
> I must say I'd like some functions to support Traversables. Those would be:
>
> array_map(), array_reduce(), array_filter(), array_walk() and
> arr
Hi Ionut,
Am Dienstag, den 28.10.2008, 16:00 +0200 schrieb Ionut Gabriel Stan:
[...]
> While we're at this and considering the new lambdas that we now have
> in the language I must say I'd like some functions to support
> Traversables.
Nevertheless I agree that this would be a great feature, I wo
While we're at this and considering the new lambdas that we now have in
the language
I must say I'd like some functions to support Traversables. Those would be:
array_map(), array_reduce(), array_filter(), array_walk() and
array_walk_recursive()
Although I'd rather want a class (because the a
Hi Andrei,
Am Montag, den 27.10.2008, 11:34 -0700 schrieb Andrei Zmievski:
[...]
> I would say "no" for 5.3. But for 6 it would be fantastic to have all
> array-related
> operations supporting ArrayAccess interface, where possible.
+1 for this.
cu, Lars
--
Jabber: [EMAIL PROTECTED]
Webl
Sean Coates wrote:
I was hoping someone would revive this thread (-:
In Habari, we have/had an ArrayObject that we passed to the view
(theme). As far as the theme knows, this is an array (but it has extra
methods if the theme is particularly smart).
Unfortunately, this breaks in 5.3, because
btw. this also affects quite a few other functions: next/current/
key/...
at least ... and maybe more after using the "new" parameter parsing
API.
I would say "no" for 5.3. But for 6 it would be fantastic to have
all array-related operations supporting ArrayAccess interface, where
possible
Johannes Schlüter wrote:
btw. this also affects quite a few other functions: next/current/key/...
at least ... and maybe more after using the "new" parameter parsing API.
I would say "no" for 5.3. But for 6 it would be fantastic to have all array-related
operations supporting ArrayAccess inter
On Fri, 2008-10-24 at 10:05 -0700, Stanislav Malyshev wrote:
> Hi!
>
> > nope that would mean that some scripts might work different between 5.2
> > and 5.3, now one gets an error. consider such a script:
>
> Just so it is clear - some scripts ALREADY work differently, that's why
> it says "BC b
Hi!
In fact, all HASH_OF was removed in standard/array.c, and that's
already is mentioned implicitly though, as
"The functions next()/current/… don't take objects anymore as
parameters. For accessing their properties using this way you have to
cast the objects to arrays first."
... is a very "
Hi!
nope that would mean that some scripts might work different between 5.2
and 5.3, now one gets an error. consider such a script:
Just so it is clear - some scripts ALREADY work differently, that's why
it says "BC break".
In <= 5.2 it will return the value of $o->prop, in 5.3 it would
On Fri, 2008-10-24 at 13:15 +0400, Alexey Zakhlestin wrote:
> On Fri, Oct 24, 2008 at 1:05 PM, Ionut Gabriel Stan
> <[EMAIL PROTECTED]> wrote:
> > But wouldn't be useful to at least accept objects implementing ArrayAccess?
>
> sounds like a good idea to me
nope that would mean that some scripts m
Hi Stas,
2008/10/23 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Hi!
>
>>> I notice that 5.3 differs from 5.2 in how array_key_exists treats
>>> objects. In 5.2, if the second parameter (array) is allowed to be object
>>> and HASH_OF is applied to it. However, in 5.3 it would produce a warning
>>> re
On Fri, Oct 24, 2008 at 1:05 PM, Ionut Gabriel Stan
<[EMAIL PROTECTED]> wrote:
> But wouldn't be useful to at least accept objects implementing ArrayAccess?
sounds like a good idea to me
>
> On 10/23/2008 23:40, Mark van der Velden wrote:
>>
>> Stanislav Malyshev wrote:
>>
>>>
>>> Hi!
>>>
>>> I n
But wouldn't be useful to at least accept objects implementing ArrayAccess?
On 10/23/2008 23:40, Mark van der Velden wrote:
Stanislav Malyshev wrote:
Hi!
I notice that 5.3 differs from 5.2 in how array_key_exists treats
objects. In 5.2, if the second parameter (array) is allowed to be obj
Hi!
I notice that 5.3 differs from 5.2 in how array_key_exists treats
objects. In 5.2, if the second parameter (array) is allowed to be object
and HASH_OF is applied to it. However, in 5.3 it would produce a warning
requiring an array if object passed to it. Was it intentional?
Maybe the problem
Stanislav Malyshev wrote:
> Hi!
>
> I notice that 5.3 differs from 5.2 in how array_key_exists treats
> objects. In 5.2, if the second parameter (array) is allowed to be object
> and HASH_OF is applied to it. However, in 5.3 it would produce a warning
> requiring an array if object passed to it. W
Hi!
I notice that 5.3 differs from 5.2 in how array_key_exists treats
objects. In 5.2, if the second parameter (array) is allowed to be object
and HASH_OF is applied to it. However, in 5.3 it would produce a warning
requiring an array if object passed to it. Was it intentional?
Maybe the probl
57 matches
Mail list logo