Hi,
is it by itention, that there is no zend_update_property_resource in
zend_API.c (as of 5.5.12)?
What is the usual and official way to add such a function and what can I do
to make it happen?
If such a thing was added, would this be considered an api change - i.e.
the zend api number would be adjusted?
Curious greetings
Nico
Hi,
is it by itention, that there is no zend_update_property_resource in
zend_API.c (as of 5.5.12)?
The reason most likely is that nobody needed it, yet. I also don't see
the need right now:
* resources are handled as zvals, thos can be passed by
zend_update_property(). The other are just wrappers creating the
zval first.
* Usage of resources is discouraged, instead of a resource use an
object (extend zend_object to store pointers etc.)
What is the usual and official way to add such a function and what can I do
to make it happen?
The typical case that a developer who has a need creates a patch and
depending on impact and the developer's brevity pushes it, sends it to
the ist or creates an RFC. Developers without karma can only do the
later (or now somebody with karma)
If such a thing was added, would this be considered an api change - i.e.
the zend api number would be adjusted?
Edge case. By strict rules yes, but there are enough previous examples
where we added APIs. Depends on brevity and need as above ;-)
johannes
>
> > Hi,
> >
> > is it by itention, that there is no zend_update_property_resource in
> > zend_API.c (as of 5.5.12)?
>
> The reason most likely is that nobody needed it, yet. I also don't see
> the need right now:
>
> * resources are handled as zvals, thos can be passed by
> zend_update_property(). The other are just wrappers creating the
> zval first.
>
Of course it is no big deal to use zend_update_property and create the zval
myself :)
> * Usage of resources is discouraged, instead of a resource use an
> object (extend zend_object to store pointers etc.)
>
Didn't know that usage of resources was discouraged... Nearly all my
knowledge comes from Sara's great book (btw. if you read this Sara, I'd
love to see and buy a refreshed version!) and my own field tests.
When you say "use an object", do you refer to the way described in [1]?
From what I've read so far, this way sounds more complex than just
registering a resource.
Could you elaborate a bit on the rationale behind this recommendation?
> > What is the usual and official way to add such a function and what can I
> do
> > to make it happen?
>
> The typical case that a developer who has a need creates a patch and
> depending on impact and the developer's brevity pushes it, sends it to
> the ist or creates an RFC. Developers without karma can only do the
> later (or now somebody with karma)
>
> > If such a thing was added, would this be considered an api change - i.e.
> > the zend api number would be adjusted?
>
> Edge case. By strict rules yes, but there are enough previous examples
> where we added APIs. Depends on brevity and need as above ;-)
>
> johannes
>
>
Thanks for the detailed info!
Greetings
Nico
[1]
http://www.phpinternalsbook.com/classes_objects/custom_object_storage.html
> > * resources are handled as zvals, thos can be passed by
> > zend_update_property(). The other are just wrappers creating the
> > zval first.
> >
>
> Of course it is no big deal to use zend_update_property and create the zval
> myself :)
I think you'd have to pass all arguments of ZEND_REGISTER_RESOURCE to
such a function. For that to work you'd need the resource type
identifier. (le_foo), which usually is static in a C file, thus you
could use it only in few cases, which seem unlikely to me considering
resources being discouraged (see below)
> > * Usage of resources is discouraged, instead of a resource use an
> > object (extend zend_object to store pointers etc.)
> >
>
> Didn't know that usage of resources was discouraged... Nearly all my
> knowledge comes from Sara's great book (btw. if you read this Sara, I'd
> love to see and buy a refreshed version!) and my own field tests.
> When you say "use an object", do you refer to the way described in [1]?
> From what I've read so far, this way sounds more complex than just
> registering a resource.
> Could you elaborate a bit on the rationale behind this recommendation?
They are (incomplete list)
* slower than objects for many operations
* have an api with some weird behavior (some operations give
errors which are hard to catch as extension author)
* any people consider OO APIs nicer
* resources can't be introspected by PHP level debuggers, var_dump
etc. whereas objects can provide required hooks
(For the performance aspect I once created an extension for a quick
demonstration http://marc.info/?l=pecl-dev&m=135774573910117&w=2
https://github.com/johannes/resvsobj )
> [1]
> http://www.phpinternalsbook.com/classes_objects/custom_object_storage.html
http://www.phpinternalsbook.com/classes_objects/custom_object_storage.html#overriding-create-object
is the relevant section.
johannes
Hi!
[...]
* Usage of resources is discouraged, instead of a resource use an object (extend zend_object to store pointers etc.)Didn't know that usage of resources was discouraged... Nearly all my
knowledge comes from Sara's great book (btw. if you read this Sara, I'd
love to see and buy a refreshed version!) and my own field tests.
When you say "use an object", do you refer to the way described in [1]?
From what I've read so far, this way sounds more complex than just
registering a resource.
Could you elaborate a bit on the rationale behind this recommendation?They are (incomplete list)
* slower than objects for many operations * have an api with some weird behavior (some operations give errors which are hard to catch as extension author) * any people consider OO APIs nicer * resources can't be introspected by PHP level debuggers, var_dump etc. whereas objects can provide required hooks
I see. In fact I use an OO API, ist's just that the object internally
stores a connection resource (i.e. a struct containing stuff I need)
in a private property.
The first version of the extension was not OO, so it seemed straight
forward just to wrap the connection resource within a class, so that
you don't need to pass it around in userspace all the time.
Extending zend_object to store my data structures sounds as the next I
should take to further "objectify" my extension.
Thanks for the pointers!
Greetings
Nico