On Thu, Mar 7, 2013 at 7:10 AM, Bob Weinand <bobw...@hotmail.com> wrote:

> Am 7.3.2013 um 00:32 schrieb Stas Malyshev <smalys...@sugarcrm.com>:
>
> > Hi!
> >
> >> RFC updated.
> >>
> >> Any other comments about this RFC?
> >
> > Could you provide a use case for this - which practical value this has?
> >
> > It also still contains factually incorrect claim that unset() is a
> > function and that there's some "inconsistency" in the fact that it does
> > not return value.
> >
> > Also, it is not clear what false returned from unset() actually means -
> > did it fail to unset the value (i.e., it is still set) or there was
> > nothing to unset (i.e., it is still not set)?
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> Hi!
>
> The main practical value is in the __unset magic method. You can now
> communicate through the "proper" way of a language construct with an
> __unset method. (success or failure)
>

The practical value in __unset is that you can unset an unavailable
"property".  The goal of unset has never been to communicate anything.  It
simply destroys a variable.  Furthermore, if you're looking to identify,
based on your examples, if you need to do cleanup work if a variable is
set, your application should check to see if that value is set.  Unset is
part of the cleanup work itself.

It would be nice to see actual use cases in an application rather than
examples showing that your very specific use cases would work with this
change.  I've yet to see any value added by this RFC.


>
> I've added a code example to the RFC.
>
> Bob Weinand
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Reply via email to