isset() isn't defined for lazy-loading properties, they're either set or not set. Not "not currently set, but could be in the future". Therefore, is it correct or incorrect to define it one way or another in our application's objects?
In the current implementation, PHPTAL makes an active attempt at stopping me from having __isset defined in a way logical for the rest of my application. My patch fixes that, and doesn't change anything if you have decided to implement __isset the other way. -- #Terin Stock Undergraduate, Computer Science (CISE), University of Florida On Tuesday, June 28, 2011 at 11:34 AM, Kornel Lesiński wrote: > On Tue, 28 Jun 2011 07:52:06 +0100, Ivo Võsa <i...@insert.ee > (mailto:i...@insert.ee)> wrote: > > > > I think it's illogical or buggy. You're saying it's not set, but then > > > you expect it to be set anyway. > > > > > > If you have lazily-loaded properties, then you should simply return > > > *true* from __isset() for such properties. > > But think other way. __isset() returns true and then after that __get() > > returns NULL. I think that it is even more illogical. > > It's not consistent with behavior of isset() indeed (it's more like > property_exists(), which may be useful to some), but if you don't want > that case to happen, it's up to you to implement __isset() correctly so > that it doesn't happen. PHPTAL doesn't stop you from doing that. > > -- > regards, Kornel Lesiński > > _______________________________________________ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com (mailto:PHPTAL@lists.motion-twin.com) > http://lists.motion-twin.com/mailman/listinfo/phptal
_______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
