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,
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.
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
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
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
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!
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!
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
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
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
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
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 hash pointer, but
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,
null
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
I meant '' actually.
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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, which means they
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
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
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)?
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
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
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
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 unexpected
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
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
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
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,
i.e.
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.e. just
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
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
ArrayAccess
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 iterating
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
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
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!
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
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
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]
Weblog:
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
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
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
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,
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
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
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.
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,
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
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 notice that 5.3 differs
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
requiring an
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 might
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.
?php
class Foo extends ArrayAccess {
public $prop = 42;
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
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 break.
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
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. Was it
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
56 matches
Mail list logo
