Ignore this patch for now, I'll get these issues addressed and I also want to improve the performance a bit.
Felipe, I'll check out those failing tests, I found the CODING_STANDARDS doc and will read it. With regards to performance, I'm creating the __getHours string on each invocation. I see that Hours has the zend_literal value. What would be the best place to cache the hash_value for future calls? Alternatively, what about adding a get/set function pointer to the property to avoid string manipulation/hash calculation? Only issue I see is larger (much larger?) memory footprint for storing two additional pointers for every class property? -Clint -----Original Message----- From: Felipe Pena [mailto:felipe...@gmail.com] Sent: Sunday, December 04, 2011 10:05 AM To: Clint M Priest Cc: Pierre Joye; internals@lists.php.net Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation 2011/12/4 Felipe Pena <felipe...@gmail.com>: > Hi, > > 2011/12/4 Clint M Priest <cpri...@zerocue.com>: >> Updated patch w/o white-space: >> http://www.clintpriest.com/patches/accessors_v1.patch >> >> In the end it is a relatively simple patch. The new syntax effectively >> creates internal functions on the object and the system looks for those >> functions and calls them at the appropriate time. >> >> Example: >> class z { >> public $Hours { >> public get { return $this->_Hours; } >> protected set { $this->_Hours = $value; } >> } >> } >> >> Defines: >> $o->__getHours(); >> $o->__setHours($value); >> >> Standard __get()/__set() functionality checks for the more specifically >> defined function name and calls them. I thought this would make the most >> sense since it would allow us to leverage the existing inheritance >> functionality. This comes out with respect to interfaces and traits in that >> only errors had to be changed (for clarity) on interfaces and no changes to >> traits were necessary to support the new functionality. >> >> For the automatic get/set functionality, I essentially built the function >> body myself within zend_do_end_accessor_declaration(). One point of >> contention here is that internally it defines a __$Hours property which >> would be accessible from various points. I believe the standard C# get/set >> does not allow any access to the underlying data storage. In order to >> accomplish that there would need to be some non-standard storage or a >> super-private level or something. I did not explore that possibility as of >> yet. >> >> I did add a couple of convenience functions that may already be available in >> some other form I was not aware of, such as strcatalloc or MAKE_ZNODE(). >> >> --Clint >> >> -----Original Message----- >> From: Pierre Joye [mailto:pierre....@gmail.com] >> Sent: Sunday, December 04, 2011 4:50 AM >> To: Clint M Priest >> Cc: internals@lists.php.net >> Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation >> >> hi Clint! >> >> >> Thanks for your work so far! >> >> On Sun, Dec 4, 2011 at 1:33 AM, Clint M Priest <cpri...@zerocue.com> wrote: >> >>> What are the next steps to get this added to some future release? >> >> Let discuss the implementation and how it works, then you can move to the >> voting phase. There is no need to hurry as the next release where this patch >> could go in is next year. >> >> Cheers, >> -- >> Pierre >> >> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, >> visit: http://www.php.net/unsub.php >> > > I've fixed the zend_compile.c and zend_object_handlers.c to build with > --enable-maintainer-zts. (some TSRMLS_CC missing and TSRMLS_DC usage > instead of TSRMLS_CC) Other thing I have noticed that you have not > followed our coding standards about brackets and comments (we don't > use the C++ style one). And about the comments looks as the patch > isn't finished or you just forgot the remove them? > > http://dpaste.com/665851/plain/ > > -- > Regards, > Felipe Pena Check out also the failing tests in Zend/tests/* (including segmentation fault) -- Regards, Felipe Pena
