Re: Re: internals Digest 24 Apr 2012 22:20:08 -0000 Issue 2675

On Tue, Apr 24, 2012 at 10:10 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote: > There's already an __isset() magic method that does exactly this: > > http://us2.php.net/manual/en/language.oop5.overloading.php#object.isset I know. In my opinion, that was a mistake, and if I catch anyone on my team using that, I will have to slap them around some ;-) If you think consistency is paramount, I'm not going to argue with that, nor would I persist in arguing against this feature... >> I would suggest making the unset-method optional for properties, and >> the default behavior for unset($time->Hours) would be >> $time->Hours=null when no unset-method is implemented. > > Agree there.  The only other sane way of handling that would be to > raise an error "trying to unset an accessor property"...  Or it would > try to unset the true public variable by that name, and hence > unsetting nothing... Yeah, that was my first thought - but it doesn't seem very "php" to throw errors when you're trying to do something that can behave in a meaningful way without forcing you to write tedious boilerplate. >> The "readonly" keyword in my opinion is redundant - properties are >> naturally read-only (or write-only) if you implement only the get or >> set method, same as any other language. No need to break common >> language conventions here. > > Well, it's redundant for a single class.  It's not redundant with > inheritance.  Otherwise a child class could define a writer for that > property, which may be undesirable...  Then again, what are the use > cases for an enforced read-only (or write only for that matter)...? In my opinion, that's the kind of thinking that made Java overly ceremonious. If I have a real reason to make something writable that wasn't writable in the base-class, why make that harder than it has to be? We're talking about a tiny fraction of cases where this is even a real concern in the first-place - things that are read-only tend to be read-only for a reason... for example, if you have a property that returns the number of users currently active on your website, or the current date/time, how or why would you make those writable? I think confusing things with yet another keyword is completely overkill for such a small amount of marginal cases. Let's not encourage artificial limitations on code extensibility, for things that < 1% of users are likely to abuse in a lifetime.