Re: Property Accessors v1.2

Hi! > That makes some sense, still the issue Nikita brought up is that the > __getHours() should not be callable. I don't see any use case for this requirement. What *requires* that it won't be callable and why it is so necessary that we introduce additional complexity into the engine just to do it? > This isn't the way isset() works, isset() will return true for a > variable with a value of 0 Exactly my point. Your code (with != NULL) will return false while real isset() will return true. > AFAIK, there is no way to implement isset() in the same way, see my > previous post about how isset() already causes a fatal error against > the return value of a function. Of course there is. Again, you're confusing implementing it in PHP (which also possible but harder) and doing it in the engine (which should be as easy as calling right functions/opcodes). > When you say "check" do you mean "not allowed to compile?" There is > a runtime check that favors a property over an accessor, again Nikita > wants to invert that and I agree. I mean issuing E_STRICT or whatever we do in other cases of LSP violations. > This is not true, see my previous post demonstrating that isset(a()) > causes a fatal error. I'm not talking about applying isset to non-variable. isset(blah bah blah) will also cause a fatal error. I'm talking about applying isset to a proper variable (or whatever is looking as one). isset($foo->bar) should never fail (to a reasonable degree - if you have accessor that gets out of memory, etc. we can't do much there) however $foo->bar is implemented underneath - it should only return true/false. > public read-only $xyz; - Tells me that the property $xyz cannot be > written to and furthermore cannot be over-ridden (the purpose of the > read-only keyword). > > To be clear, the read-only keyword specifically means that no > sub-classes may make this property writable, in other words the > "non-writable" aspect means it is final. This sounds way too complex and too much magic. I'd rather have people implement it in user-space than introduce this complex and un-obvious convoluted concepts into the language. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227