Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72981
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.45 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: Fri, 7 Mar 2014 02:29:49 +0900
Message-ID: <CAGfRu7NmgbkiteY_auprZCfYCaWgSV2BVHHTCMihb=Kjt0LvKw@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)")

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.