Re: Re: Property Overloading RFC

php.internals

boots

21 years ago
Derick Rethans wrote:
> Problems: > 1. There is no way to document the 'virtual' properties with any of > the existing documentation tools (such as phpdoc and doxygen) > 2. There is no way how the magic methods know if a specific 'virtual' > property exists or not as those properties are not declared
usually
> - unless you define an array with property names as a class > constant (which is not allowed either). > 3. There is no way for the magic methods to return a meaningfull > error when a property doesn't "exist". Of course it is possible to > throw an error with "trigger_error" or "throw" in case a property > doesn't "exist" in a specific class, but the file and line numbers
> would not match the actually get/set action. debug_backtrace() can
> be used to retrieve the correct file and line, but as you have to > do this for every class where you want to use setters and getters > *and* you have to implement your own error message rendering > function this is not really a suitable option either.
As far as introspection (points 1 and 2), would it be reasonable to allow __get/__set to be called without any parameters in which case they would be expected to optionally return an array or object designating the properties that they support? I know that this is somewhat magical but dynamic features are somewhat magical to begin with -- which is part of their charm. FWIW, it would be nice if there was a way for __get/__set to support references. Greetings. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Marcus Börger

21 years ago
Hello boots, Thursday, August 4, 2005, 6:29:51 AM, you wrote:
> Derick Rethans wrote: >> Problems: >> 1. There is no way to document the 'virtual' properties with any of >> the existing documentation tools (such as phpdoc and doxygen) >> 2. There is no way how the magic methods know if a specific 'virtual' >> property exists or not as those properties are not declared > usually >> - unless you define an array with property names as a class >> constant (which is not allowed either). >> 3. There is no way for the magic methods to return a meaningfull >> error when a property doesn't "exist". Of course it is possible to >> throw an error with "trigger_error" or "throw" in case a property >> doesn't "exist" in a specific class, but the file and line numbers
>> would not match the actually get/set action. debug_backtrace() can
>> be used to retrieve the correct file and line, but as you have to >> do this for every class where you want to use setters and getters >> *and* you have to implement your own error message rendering >> function this is not really a suitable option either.
> As far as introspection (points 1 and 2), would it be reasonable to > allow __get/__set to be called without any parameters in which case > they would be expected to optionally return an array or object > designating the properties that they support? I know that this is > somewhat magical but dynamic features are somewhat magical to begin > with -- which is part of their charm.
To complicated and uses one thing to do two completley different things which confuses everyone.
> FWIW, it would be nice if there was a way for __get/__set to support > references.
Best regards, Marcus

boots

21 years ago
--- Marcus Boerger <helly@php.net> wrote:
> Hello boots, > > Thursday, August 4, 2005, 6:29:51 AM, you wrote: > > As far as introspection (points 1 and 2), would it be reasonable to > > allow __get/__set to be called without any parameters in which case > > they would be expected to optionally return an array or object > > designating the properties that they support? I know that this is > > somewhat magical but dynamic features are somewhat magical to begin > > with -- which is part of their charm. > > To complicated and uses one thing to do two completley different > things which confuses everyone.
Why is that more complicated than adding more keywords and/or property mechanisms? The idea is not to add anything at all except a new signature for __get and one for __set allowing them to be self-describing. So this should still be BC and it would additionally be optional. In terms of one thing doing two -- this is, after all, in regards to an overloading mechanism; I would think that people using overloading would find the concept a single method with two different signatures returning two different types quite natural. The fact that the first type is really an introspection of the second type is nice to me. Thanks for your reply, Marcus. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com