Re: RFC: Property get/set syntax (added isset/unset and references)

Hi! >> - Variables may be used as input to out/ref arguments. Properties >> may not. This will probably be true for properties too, in some cases. However, it is in no way an advantage. >> - Properties may throw exceptions - variables will never do that. In PHP, properties can not throw exceptions unless your code does, and variable access can throw exceptions too if you do that in __get. >> - Properties may have side effects or take a really long time to >> execute. Variables have no side effects and will always be as fast >> as can be expected for the given type. Again, depends on __get. >> - Properties support different accessibility - variables do not In PHP, variables have access modifiers. >> - When using reflection the properties and fields are treated as >> different MemberTypes so are located differently (GetFields vs >> GetProperties for > example) It may be so, but I don't see where there's an advantage. So, none of these explain why would one want to create "default implementation" property. Could you explain? > Some of these above example still apply (reflection, execution time), > so the automatic implementations may simply be there as a way for > authors to indicate their intention to make them execute code at a > later time. If they would want to make them execute code at a later time, they could convert them to properties then. I think the whole point of introducing properties is that they would work transparently for the client, so if we saying we'd have to pre-define them as properties that defeats the whole purpose of it. I think as proposed "default implementation" only makes it more confusing as it works differently from user-space implementations. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227