Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.54 as permitted sender)
MIME-Version: 1.0
Sender: chobieee@gmail.com
In-Reply-To: <531675D6.1030203@sugarcrm.com>
References: <5307B1FE.1020604@marc-bennewitz.de>
	<CAGfRu7NGLvwQh-1R7tLpoxiPrqqya_Bpm+8_VvdxvhgviEf31A@mail.gmail.com>
	<531675D6.1030203@sugarcrm.com>
Date: Thu, 6 Mar 2014 22:53:26 +0900
Message-ID: <CAGfRu7N-_09RUnDJBfSkxNqhrH94kRM_Vca2ixXJdoSeg9-+OQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Marc Bennewitz <php@marc-bennewitz.de>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [php6] OOP resources
From: chobieeee@php.net ("Shuhei Tanuma (chobie)")

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
         ` UVStream
                          `UVHandle

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