Re: Patch: getters/setters syntax Implementation

The difference being *where* the functionality gets mapped. It's not about making something "look like something else", it's about requiring more userspace definitions. Functionality within get {} and set {} can (and should IMO) be implemented outside of userspace code. Whether that means another union within op_array or a completely new structure mapped to a property zval and bitmap added to the zend_uchar type identifying it as an accessor.... I'm saying be creative - don't just implement something halfway for the sake of getting it done. On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote: >> if we're attempting to get around __set/get, let's not replace them with > more method implementations > > I don't understand this argument. Accessors are methods - making them look > like something else won't change that fact. > > In C#, type-hinted properties with automatic getters/setters actually > compile down to two method implementations, while implemented > getters/settings do the same, substituting "value" for whatever is required > to access the auto-implemented backing field. > > > On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch <will.fitch@gmail.com> wrote: > >> >> On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote: >> >>> I agree with all of those points - the extra indentation looks messy, and >>> yes, type hints are important. It does fit better with PHP in general. >>> >>> It would be nice to also have support for automatic backing fields in >>> addition though - so something simple like this: >>> >>> class BlogPost >>> { >>> private $_author; >>> >>> public get author() >>> { >>> return $this->_author; >>> } >>> >>> public set author(Person $value) >>> { >>> $this->_author = $value; >>> } >>> } >> >> I don't like this approach. All efforts (which I'm currently part of) to >> implement type hinting return values will be compromised. If you want to >> implement accessors, keep them within a syntax that makes sense. >> Personally, I support the C# style as much as possible. Methods are >> already overused for purposes they shouldn't be, so if we're attempting to >> get around __set/get, let's not replace them with more method >> implementations. >> >>