Re: [php6] OOP resources

From: Date: Thu, 06 Mar 2014 17:29:49 +0000
Subject: Re: [php6] OOP resources
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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 <[email protected]>:
> 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.


Thread (10 messages)

« previous php.internals (#72981) next »