Re: Re: plua merged into lua

From: Date: Mon, 15 Aug 2011 21:35:54 +0000
Subject: Re: Re: plua merged into lua
References: 1 2 3  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-8460@lists.php.net to get a copy of this message
Ah and an additional comment: I won't go to "stable" directly but release as beta first and (try to) get some people to test. johannes On Mon, 2011-08-15 at 23:34 +0200, Johannes Schlüter wrote: > Hi, > > I'm unfortunately missing the time to go through this properly but to > answer at least a bit more than I did on IRC a few comments: > > In php_lua.h line 90-110: > This code is dependent on C99 and some compilers. Even when more code I > prefer having the long version in the code instead of these non-portable > shortcuts. > Additionally one should use php_error_docref() this formats the error a > bit nicer and can directly link to the documentation. Also: why is > lua_error() using E_USER_ERROR not E_ERROR? The USER ones are meant to > be used from userspace. > > In lua.c I do not understand why you need the LUA_G(instances) table. > The individual instances should be stored in the object (as is > lua_obj->L = L; ) and manged via that object. > > In lua.c I see that Lua::register seems to only accept global PHP > functions as a callback. Is there no way to attach custom data to the > lua closure, so we can store zend function pointers (as returned by the > "f" modifier to zend_parse_parameters) so object methods and closures > work, too? > Related to that I also see the usage of a property _callbacks. If the > information is needed it should probably stored in the object structure, > this actually might be what is needed for what i said before. Secodly if > the property is kept it is strange: The class Lua is marked as final, > while the property is set to protected. This combination doesn't really > make sense. Maybe it should be private. Secondly it is static, while > callbacks are set by object instance. > > In lua.c php_lua_send_zval_to_lua's case IS_ARRAY should have a > recursion protection. (see HashTable.nApplyCount, recursion is easy: $a > = array(); $a[] &= $a; ) > > In lua.c php_lua_send_zval_to_lua I'm not sure about the array > conversion. This will only work for objects making use of "normal" > properties. It will cause trouble with private/protected properties (You > get \0-bytes in the result). Maybe it makes sense to create an interface > like this: > interface LuaConvertable { public function getElements() } > which returns a list of all properties and their name and value as they > should be exported. If not one has to think about iterators and using > get_property object handlers. > > In lua.c PHP_METHOD(lua, call) - why does this function exist? I think > it should be an alias in the function table (PHP_MALIAS). I also think > call should be the primary name and __call the alias to it. > > In lua.c in php_lua_get_zval_from_lua, if a TTABLE is returned and the > key is neither numeric nor a string there should be a warning for the > user. Maybe it also makes sense not to use key = > php_lua_get_zval_from_lua(L, -2 TSRMLS_CC); but a specific handling > routine. > > In lua.c proto Lua::getVersion() should be renamed from getversion to > getVersion ;-) > > In lua.c Lua::register probably should be renamed to something like > Lua::registerCallback. > > In lua.c all(?) PHP_METHODs: After a failure in zend_parse_parameters > (zpp) do a simple "return;" not WRONG_PARAM_COUNT. zpp will already > report an error, way more precise than WRONG_PARAM_COUNT. > > As an additional comment, not tooo relevant here: the php_{$extname}.h > header should be short and contain little more than the > phpext_{$extname}_ptr as this file is included from > main/internal_functions.c along with all other extension's headers when > doing a static build and therefore increases compile times and increases > the risk of symbol conflicts (especially when including "random" library > headers) which can be avoided. > > > johannes > > On Thu, 2011-08-11 at 11:48 +0800, Laruence wrote: > > Hi: > > johanees, do you think it's the time to make a release now? > > (the issues you metioned last time: version $Id, I will subtitute > > it before release); > > > > > > thanks > > > > 2011/8/6 Andreas Streichardt <andreas.streichardt@googlemail.com>: > > > Hi! > > > I just had a quick look at the code and it looks very good and way more > > > professional than my code :) > > > So i would say: release it. I will update a few links i set to my extension > > > to the pecl homepage. > > > Kind regards, > > > Andreas Streichardt > > > > > > > > > Laruence <laruence@php.net> hat geschrieben: > > > > > > > > > Hi: > > > if I can get your agreement before next sunday(14 Aug), > > > I will make the first relase with version 1.0.. > > > > > > alos doc is in process. > > > > > > thanks > > > > > > 2011/8/4 Laruence <laruence@php.net>: > > >> Hi: > > >> > > >> I have merged plua src into lua, add add package2.xm to build pecl > > >> package. > > >> > > >> could you plz review my codes when you are free? > > >> > > >> thanks > > >> > > >> -- > > >> Laruence Xinchen Hui > > >> http://www.laruence.com/ > > >> > > > > > > > > > > > > -- > > > Laruence Xinchen Hui > > > http://www.laruence.com/ > > > > > > > > > >

« previous php.pecl.dev (#8460) next »