On Tue, Sep 23, 2003 at 11:44:29AM -0400, Jay Smith wrote:
>
> Is this fix really causing this much grief? Throwing an E_NOTICE isn't a BC
> break. It still works as before, it just throws the E_NOTICEs now. This was
> meant to be a bridge to the behaviour used in PHP 5, which, like other
> array_*() functions, doesn't work on non-arrays at all. (Although that fix
> for PHP 5 is debatable, I suppose.)
Well, array_splice() accepts non-array arguments in the same manner that
array_merge did before, so it's as inconsistent as it was before the
'fix'.
> The function is called array_merge(), not null_merge() or string_merge().
So why does str_repeat(10,10) work? It's not called number_repeat.
PHP is a dynamically typed language, if a function gets an argument that
does not "fit" i expect it to cast, if it does make sense in any way...
and merging a single element into an existing array, or merging two
elements to form a new array does make sense IMHO.
Of course, if a function expects a resource, a cast doesn't make much
sense - except i could think of a few cases where it could fopen() and
fclose() a resource on the fly. Same with objects.
Btw, the default (string)$somearray output "Array" is not satisfactory
IMO, i think a join('',$array) or something like that would be more
useful - that would have the benefit of actually being useful ;)
> The change was to make it act more like other array functions, like
> array_intersect() or array_sum(), which also check parameters for arrays.
Like i said, array_splice() acts like the old array_merge()...
And this behaviour is documented.
I think adding strict checks is the wrong way, because it breaks BC (at
least it fills error logs). If a consistent behaviour is desired,
typecasts should be added to the functions which don't support it.
> What's the consensus? Keep the change or revert? Personally, I think it's
> more consistent if it acts like the other array functions, but if it's
> causing a lot of headaches...
As you might have guessed, i'm in favour of reverting it ;)
--
Regards,
Stefan Walk
<[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
