>>>> public property Hours read getHours write setHours; >>> >>> I actually like that, though I think we should support the whole >>> existing semantics, i.e. get/set/isset/unset. And probably keep the >>> names, so we don't call the same thing both "read" and "get". >> >> This doesn't make sense. To call isset() on a property, would be to ask >> if the property itself exists. But once defined, a property always >> exists >> (think of methods, for example). >> >> (Sorry for sending again Stas, I forgot to reply all) >> - Dennis > > True, but if part of the intent (as noted in a previous email) is to > provide a mechanism that looks to the outside world like a class member, > and therefore one can switch between the two without breaking an API, > then isset/unset should have some sort of useful meaning.
This is the exact issue Stas touched upon earlier, and you are both absolutely right. If isset/unset are not supported, than class variables and properties cannot truly be interchangeable. However, my issue is this: If get/set/isset/unset are all supported as methods in a property, I do not think it wise to require isset/unset to be created - they should be optional, for the few times that they would be useful. However, the question is, if you do not define isset/unset, then what do they do? isset could always return true, but what about unset? Does it just do nothing? That does not make sense from the perspective of a user of the class. Maybe if you call unset, than isset now returns false. Then once you call set again, isset now returns true? That would be consistent with how variables work... - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
