Hi,
here another idea for PHP 6 the simply means removing the datatype
"resource" because and convert current resources into classes/objects
as it's already done with GMP.
Because resources are simply a pointer to a somewhere described data
structure - resources are the exactly the use case for objects.
To be bc current resources should be instances of an interface
"Resource" and the function "is_resource" would work similar as
"$resource instanceof Resource".
I haven't enough knowledge about the internals but couldn't that be
implemented in a bc way by changing resource macros to handle objects?
Thoughts,
Marc
Hi,
here another idea for PHP 6 the simply means removing the datatype
"resource" because and convert current resources into classes/objects
as it's already done with GMP.Because resources are simply a pointer to a somewhere described data
structure - resources are the exactly the use case for objects.
I'm a big fan of this idea in principle, resources have always struck
me as just a messier way of dealing with objects. However, to go
through every usage of the resource type an convert them is a mammoth
task, because I don't there being any point in doing it unless the
procedural APIs that use them are given an OO overhaul. The vast
majority of the time they are used in the context of
<resource_purpose_prefix>_action_name($resource, ...$args), and if
they were converted to objects a $resource->action_name() method is
what I would expect. The procedural APIs could still be maintained,
much like MySQLi.
I don't see the goal of completely removing the resource type as being
practical or, considering how many PECL and custom extensions this
would affect, sensible. However, I'd be all for a general push to
convert/duplicate as many core resource-oriented APIs as possible to
OO APIs.
To be bc current resources should be instances of an interface
"Resource" and the function "is_resource" would work similar as
"$resource instanceof Resource".
And, more importantly, it will become a lot easier (in many cases,
simply "possible") to determine what a "resource" is actually for. In
reality is_resource() isn't hugely useful, I can't call fwrite() on a
stream context resource, for example.
Am 21.02.2014 22:13, schrieb Chris Wright:
Hi,
here another idea for PHP 6 the simply means removing the datatype
"resource" because and convert current resources into classes/objects
as it's already done with GMP.Because resources are simply a pointer to a somewhere described data
structure - resources are the exactly the use case for objects.
I'm a big fan of this idea in principle, resources have always struck
me as just a messier way of dealing with objects. However, to go
through every usage of the resource type an convert them is a mammoth
task, because I don't there being any point in doing it unless the
procedural APIs that use them are given an OO overhaul. The vast
majority of the time they are used in the context of
<resource_purpose_prefix>_action_name($resource, ...$args), and if
they were converted to objects a$resource->action_name()method is
what I would expect. The procedural APIs could still be maintained,
much like MySQLi.I don't see the goal of completely removing the resource type as being
practical or, considering how many PECL and custom extensions this
would affect, sensible. However, I'd be all for a general push to
convert/duplicate as many core resource-oriented APIs as possible to
OO APIs.
Shouldn't it be possible to change the internal resource macros to
generate objects of a specified class unter the hood?
To be bc current resources should be instances of an interface
"Resource" and the function "is_resource" would work similar as
"$resource instanceof Resource".
And, more importantly, it will become a lot easier (in many cases,
simply "possible") to determine what a "resource" is actually for. In
realityis_resource()isn't hugely useful, I can't callfwrite()on a
stream context resource, for example.
here another idea for PHP 6 the simply means removing the datatype
"resource" because and convert current resources into classes/objects
as it's already done with GMP.Because resources are simply a pointer to a somewhere described data
structure - resources are the exactly the use case for objects.
Inspired by this topic, I took a stab at refactoring the hash context resource into an object: https://github.com/php/php-src/pull/611
The most interesting thing to discuss, is probably how to describe closing a resource with objects.
Best regards
Rouven
2014-02-22 5:07 GMT+09:00 Marc Bennewitz php@marc-bennewitz.de:
Hi,
here another idea for PHP 6 the simply means removing the datatype
"resource" because and convert current resources into classes/objects
as it's already done with GMP.Because resources are simply a pointer to a somewhere described data
structure - resources are the exactly the use case for objects.To be bc current resources should be instances of an interface
"Resource" and the function "is_resource" would work similar as
"$resource instanceof Resource".
I prefer resource as It makes easier to implement bindings.
I've maintained several extensions. one of the library has 500
approximates APIs.
Imagine considering complicated OOP interface is really nightmare...
To encapsulate resource data structure to object isn't bad idea.
but zend_list_insert is more convenient than
zend_object_store_get_object, isn't it?
I think ambiguity is one of good point of PHP.
On Tue, Mar 4, 2014 at 9:16 AM, Shuhei Tanuma (chobie)
chobieeee@php.net wrote:
To encapsulate resource data structure to object isn't bad idea.
but zend_list_insert is more convenient than
zend_object_store_get_object, isn't it?
I am not saying that I am in favour of droping resources, but from an
internal point of view, objects are actually easier.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
I prefer resource as It makes easier to implement bindings.
I've maintained several extensions. one of the library has 500
approximates APIs.
Imagine considering complicated OOP interface is really nightmare...
You don't have to do anything different there - you can still use the
same API. With minimal effort, you can also make the API dual-purpose,
i.e. foo_bar($foo, $bar) and $foo->bar($bar) would do the same. But it
doesn't have to be that, you can also stay with foo_bar($foo, $bar) and
have $foo as object.
To encapsulate resource data structure to object isn't bad idea.
but zend_list_insert is more convenient than
zend_object_store_get_object, isn't it?
What would be the difference? It's pretty much the same API and macros
can be added to eliminate any boilerplate code. See how it's done in
intl, for example.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2014-03-05 9:54 GMT+09:00 Stas Malyshev smalyshev@sugarcrm.com:
You don't have to do anything different there - you can still use the
same API. With minimal effort, you can also make the API dual-purpose,
i.e. foo_bar($foo, $bar) and $foo->bar($bar) would do the same. But it
doesn't have to be that, you can also stay with foo_bar($foo, $bar) and
have $foo as object.
I've maintained libgit2, libuv and several entrepreneurial libraries.
occasionally, those libraries brakes BC. I have to get rid of some OOP
interfaces if they broke BC.
Eventually, I prefer procedural programming to OOP in that cases.
and resource object forcing object oriented programming I think.
for example, int git_repository_index(git_index **out, git_repository *repo);
http://libgit2.github.com/libgit2/#v0.20.0/group/repository/git_repository_index
and most developer might expect correct inheritance for resource
object. (I know this is tread off)
for example, uv_read_stop accepts tcp, pipe and tty resources.
UVTcp
UVStreamUVHandle
then uv_read_stop signature will be this.
uv_read_stop(UVStream $stream, Closure $callback);
But developer might thought why this api is not OOP like
UVStream->readStop(Closure $callback)?
I think to choose resource object is forcing objective oriented programming.
To encapsulate resource data structure to object isn't bad idea.
but zend_list_insert is more convenient than
zend_object_store_get_object, isn't it?What would be the difference? It's pretty much the same API and macros
can be added to eliminate any boilerplate code. See how it's done in
intl, for example.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
oh my god. I've missed to send my draft....
I'm not good at english so I need more time to writing reply. please
forget previous email...
Again, previous email completely broken my English and thoughts. so
please don't reference it ;'-(
2014-03-05 9:54 GMT+09:00 Stas Malyshev smalyshev@sugarcrm.com:
You don't have to do anything different there - you can still use the
same API. With minimal effort, you can also make the API dual-purpose,
i.e. foo_bar($foo, $bar) and $foo->bar($bar) would do the same. But it
doesn't have to be that, you can also stay with foo_bar($foo, $bar) and
have $foo as object.
I've maintained extensions which uses several entrepreneurial
libraries. like libgit2, libuv.
Occasionally, those libraries brakes BC. then I have to get rid of
some OOP interface when they broke it.
Eventually, I prefer procedural interface to object oriented
programming in that cases.
(also, writing an extension generator for procedural interface is easy
work. it's very handy)
Well, regrading resource object. let assume try to implement
git_repository_index function.
(git_repository_index fetches index pointer from repository pointer.)
int git_repository_index(git_index **out, git_repository *repo);
PHP interface would be this: GitIndex git_repository_index(GitRepository $repository);
GitIndex and Git repository are represents of resource objects. and I
choose procedural interface for maintainability reason.
But in this case. Most developer expects $repository->getIndex() API
isn't it? even maintainability reason.
So I think Resource object forces OOP paradigm.
And I realized resource object has another effect. for example, libuv
has several structures.
I have to implement right resource inheritance for those structures, right?
like UVTcp extends UVStream, UVStream extends UVHandle and UVHandle
extends Resource...
It would be better to implement OOP interface than choosing Resource
object I think.
What would be the difference? It's pretty much the same API and macros
can be added to eliminate any boilerplate code. See how it's done in
intl, for example.
yea, I've checked it. and this is trivial thing for PHP6. please never mind.