On Mon, 2009-07-06 at 20:52 -0400, Ilia Alshanetsky wrote:
> Last week or so there was a fairly detailed discussion on the
> internals list regarding type hinting based on my original patch.
> Since then the patch has been revised to address the major concerns
> that were identified (breakage of binary compatibility) as well
> extended with additional functionality (object hint, type casting,
> reflection support, etc...).
>
> The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt
> The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2
If I read the patch correctly it still breaks binary compatibility:
-#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name,
sizeof(#name)-1, #classname, sizeof(#classname)-1, 0, allow_null, pass_by_ref,
0, 0 },
-#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name,
sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 },
+#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name,
sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_CLASS, allow_null,
pass_by_ref, 0, 0 },
+#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name,
sizeof(#name)-1, NULL, 0, IS_ARRAY, allow_null, pass_by_ref, 0, 0 },
Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
+ /* existing type already matches the hint or forced type */
+ if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint ||
Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.
The only clean why I see for doing this is by breaking the binary
compatibility, then one could also rename "array_type_hint" and change
it's type from zend_bool to a better suited type.
Independently from this compatibility issue I'd vote -1 for 5.3.
Yes 5.3 took loooong and we should, in my opinion, try to be faster with
the next "feature release" instead of changing syntax and adding other
big features in _bugfix_ releases.
I know it is bad to wait long till new features become available (btw.
that's one of the reasons why 5.3 took so long - "let's add this feature
else we have to wait so long till we get the next major version") but
adding features and changing syntax is a pain for users and at least one
of the reasons why distributors won't update the PHP versions they are
offering (What's the current PHP version in RedHat, again? - Yes, I know
people should built PHP themselves but still...)
A thing I wish for sometime is a change to our release model but never
sat really down to do the research and write a good proposal. The basic
concept would be to have a pre announced release date (maybe +/- a few
days) and therefore a "last integration date" a few weeks/months
beforehand. Ideally the release and integration date for the next
version would be set before the integration date for the current tree is
reached. After the integration day only be bug fixes should be allowed,
no new features at all. By such a model people can plan and if a feature
doesn't make it into a release it's not rejected for an unforeseeable
future. Similar models, in different flavors, are used by at least
PostgreSQL, Ubuntu, OpenSolaris and quite a few more ... but well,
that's off-topic for this thread and I wanted to do some more research
with other projects before proposing such a thing ....
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
