[RFC] unset(): return bool if the variable has existed

Hi!

Shouldn't this fail a little bit more obvious (-> "loud")? And how is
this even possible?

Well, for example - __unset is required to do X before unsetting
variable but X fails for one reason or another and the logic dictates
that you can not unset unless X is done (for a real life example, try
exiting an app like word processor with content unsaved and when it asks
you to save/discard/cancel, click on cancel. Bingo - unset interrupted :).

or there was
nothing to unset (i.e., it is still not set)?

So I guess this is the only useful behaviour. However, I have no idea,

This behavior is already covered by isset, why duplicate it? If - and I
have no idea why - you cared if the variable was set or not, why not
just do isset?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

So I guess this is the only useful behaviour. However, I have no idea, what
this information should tell me. If I call unset() then I want to ensure,
that the variable is not set anymore, but for what reason I should need to
know, whether it was set before, or not?

I think I actually had an use case with proxies, where I wanted to know if
a property was set or not. That's useful to reset the proxy state
(basically to intercept property access) and differentiate null properties
vs non existing properties:

class Blah extends Blubb
{
    protected $prop;
    public function __construct() { unset($this->prop); }
    public function init() { $this->prop = 'stuff'; }
    public function `reset()` { return unset($this->prop); } // we now

know if init was called
}

This could be useful if I want to keep track of the state of a proxy, but
it's just an additional property to keep track of manually on the other
side. The additional property is also more explicit and easier to track.

Yes, it needs a better use case.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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)

I'm not sure how useful is that based on your example - unset could
throw the exception as well... And the whole case seems still unclear -
what is "false" supposed to mean in general case? Property didn't exist?
Property can not be unset due to special semantics?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Am 7.3.2013 um 00:32 schrieb Stas Malyshev smalyshev@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

--

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