RE: Third party object support in ZE2
| From: | Dmitry Stogov | Date: | Tue, 10 Jan 2006 07:49:25 +0000 |
| Subject: | RE: Third party object support in ZE2 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-21458@lists.php.net to get a copy of this message | ||
Hi Steph,
> -----Original Message-----
> From: Steph Fox [mailto:steph@zend.com]
> Sent: Monday, January 09, 2006 9:50 PM
> To: Dmitry Stogov
> Cc: Andrei; internals
> Subject: Third party object support in ZE2
>
>
> Hi Dmitry,
>
> I gave up on IM now, it's too slow :)
>
> Coming from the PHP-GTK project, we've noticed two areas where
> ZEND_INTERNAL_CLASS is wrongly expected to adhere to
> zend_object structure.
>
> The more important of the two stems from a change you made in
> mid-November
> in CVS_HEAD and PHP_5_1, forcing a call to
> zend_objects_destroy_object()
> when there is no obj->dtor defined. (zend_objects_API.c,
> revision 1.47.2.3).
Yes. This is my patch. It allws calling destructor in classes those extend
internal ones.
(Probably it can be reverted and all "bad" extensions should be fixed).
> Reaching that function causes a crash in PHP-GTK 2 under some
> circumstances.
> Bug report open on this behaviour at http://bugs.php.net/35871.
I reproduced this crash.
The reason that "style_helper" is incompatible with "zend_object" and it
hasn't pointer to class entry.
I suggest to fix it on PHP-GTK level. I see two ways:
1) Make "style_helper" compatible with "zend_object".
2) Pass dumy dtor handler to zend_objects_store_put()
(php_gtk++-types.c:382)
> The second is that we can't guarantee third party objects will pass
> zend_do_perform_implementation_check()... so if
> display_startup_errors is
> on, we get to know about it every time GTK+ objects break
> PHP's inheritance
> rules. Trivial patch attached appears to fix this minor
> issue without
> breaking anything currently in the test suite, but you might
> know better.
I didn't understand why we should allow to break inheritance rules?
Right now we break rules only for "parent" internal functions without
arg_info.
I think this is enough. Why should we break ZE for "bad" extensions?
May be I missed something?
BTW: The patch has mistake: ZEND_INTERNAL_CLASS should be
ZEND_INTERNAL_FUNCTION.
Thanks. Dmitry.
> - Steph
>
>
>
>
>
>