Hi all,
I would only add that it may be wise to consider whether reliance on
such behavior is worth the risks resulting from expecting behavior that
could change as PHP and the Zend Engine evolve. I have read about
several changes with PHP 5.2 that are more "strict" than previous
versions, though I don't know if there is any overlap between these two
ideas.
I won't speculate here on the likelihood or risks involved if this were
to happen. Maybe it's not that big of a deal, but most of us know
firsthand how loathsome it can be to have to fix an application that
breaks because of backward-incompatibilities in release versions. If we
can reasonably avoid the situation, that is good, and if we can easily
remedy the situation in the event of backward-compatible breaks, that is
good, too.
Without further supporting information (e.g., from contact with PHP
developers or from PHP development mailing list), however, I would
likely err on the side of caution where reasonable, making such methods
public, rather than relying on a behavior that may conceivably be
changed in future PHP versions.
Others' thoughts?
Best regards,
Darby
Gavin Vess wrote:
> It seems today is a day for coding standards ;)
>
> At the moment, I do not have a justification for making these
> __get()/__set()/__isset()/__unset() magic methods public. However, I
> can think of several reasons they should not be public, as nicely
> presented by Ralph.
>
> Can anyone think of a reasonable use case for why these methods need to
> be public? Even if we find some use case, perhaps we could still
> strongly suggest these methods be protected, unless the author has a
> very good reason for making them public.
>
> Thoughts anyone?
>
> Cheers,
> Gavin
>
> Simon Mundy wrote:
>> Hi Ralph
>>
>> I was about to ask the same thing, but your explanation makes complete
>> sense.
>>
>> Should we take this as another unofficial coding standard that these
>> magic methods should all be protected (except __construct, of course,
>> for where it needs to be public)?
>>
>>> The reason it was made protected was to prevent the masses from using
>>> the __get()/__set()/__isset()/__unset() methods directly, as that
>>> usage is frowned upon.. ie: $session->__get($name);
>>>
>>> The reason is to protect from unintentional misuse. As this scenario:
>>>
>>> $session = new Zend_Session();
>>> $var = array('foo'=>'bar');
>>> $session->__set($var, 'value');
>>>
>>> Would produce unexpected results.
>>>
>>> -ralph
>
>
