Re: RFC: C-sharp style property get/set syntax for PHP

2010/12/1 Eloy Bote Falcon <eloybote@gmail.com> > 2010/12/1 Richard Quadling <rquadling@gmail.com> > > On 1 December 2010 09:22, Stas Malyshev <smalyshev@sugarcrm.com> wrote: >> > Hi! >> > >> >> Its not a matter of consistency - Properties, as a cross-language >> concept >> >> are not meant to work that way. You need to think of a property as a >> set >> > >> > Meant by whom? Is there some law of universe that prevents us from >> > implementing the feature? >> > >> >> of two methods that just have a pretty syntax. Methods cannot be >> unset, >> >> and nor should properties be allowed to. isset() should simply tell us >> >> whether a property with the specified name is part of the class or not. >> > >> > If you need methods, why not use methods? If you mimick object >> properties, >> > however, it makes sense to make them work exactly like property, >> otherwise >> > you have to explain why they don't work this way. >> > >> >> isset() in the way you suggest would just be confusing. It would allow >> is >> >> to say that a property does not exist, when in fact it does exist. >> This >> >> is not logical. >> > >> > Sorry, from your answer I don't understand - what happens when you call >> > isset($foo->property) and unset($foo->property)? >> >> If we think of properties as this new entity for the language (rather >> than somehow massaging existing entities to fit a new usage scenario), >> then >> >> isset($instance->property) will always return true for any defined >> property. Even if the getter would return null. This is new behaviour >> and can be easily documented. isset() for a property is more like >> method_exists() than isset() on a variable. >> With regard to unset($instance->property), from the manual ... >> >> "The behavior of unset() inside of a function can vary depending on >> what type of variable you are attempting to destroy." >> >> So, we already have differing behaviour based upon context. Attempting >> to destroy a property should through a non fatal error. >> >> One idea I had was to keep just the get/set property methods and add >> to them an additional parameter ... >> >> <?php >> public $seconds { >> public set($value, $unset = False) { >> if ($unset) { >> // unset() has been called on the property. >> // In this instance $value will be Null. >> } else { >> // set the property using the supplied $value. >> } >> }, >> public get($isset = False) { >> if ($isset) { >> // isset() has been called on the property. >> // If the value is a non-destructive calculation >> then maybe >> returning the comparison of the result of the calculation to null. >> } else { >> // return the value for this property. >> } >> } >> }; >> >> So, >> >> isset($instance->property) would call $instance->property->get(True); >> unset($instance->property) would call $instance->property->set(Null, >> True); >> >> This keeps just the 2 property methods. It still allows isset/unset >> and allows the developer the option of handling them. >> >> >> >> >> -- >> Richard Quadling >> Twitter : EE : Zend >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > Why change the expected behavior of isset? If a property has not been set > then isset must return false, and that includes $foo->name = NULL. > > > Regards. > Oops, the mail has been marked has spam because of some URI. Regards.