Re: [php6] OOP resources

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