Hi Stefan, >> Unfortunately I find that to be one of the major downfalls of PHP. It >> sometimes disregards defacto standards that are set across the entire >> industry, which causes a lot of frustration for new programmers. >> Sometimes the functionality PHP adds by going its own way is worth it, >> but >> often it is just a confusing mess. Thats just my opinion though, YMMV. > > Still, if it is not consistent in itself it is worse than not following > certain designs which make sense for other languages only.
Yes, I would agree with that. >>>> isset() in the way you suggest would just be confusing. It would >>>> allow is >>>> to say that a property does not exist, when in fact it does exist. >>>> This is not logical. >>> From the docu: isset Determine if a variable is set and is not NULL >>> There is nothing confusing about isset($this->Hours) == FALSE in your >>> example if isset($this->seconds) == FALSE. >> >> Right, I understand how it would work, and the reasons why it would "make >> sense", but it just feels wrong to me. When you unset() a variable in a >> class, that whole variable is gone. Its not just hiding somewhere, its >> completely gone. If a property were to "pretend" it is not set, with an >> isset method, it would still be there - just hiding. That is why it >> does not make sense to me. > > The main problem here is that unset and isset are not symmetric. > > isset() basically means there is a value. > Where unset() destroys the _holder_ of the value. > > In that sense, unset is special since it works on another level, on the > same level as property_exists(). > > There are several possible approaches, but the main point here is that at > least isset() still makes sense. > property_exists() and unset() should be dealt with carefully in another > way. Ok. Well isset() could just run the get handler for the property, and if it is null, return false, and otherwise return true. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
