Kornel:
Thanks!
It's early enough in my application, that I can go ahead and change my
behavior, so that's not much of an issue.
> Thank you for your patch. It's not fun to reject patches, I'm sorry for that.
No problem, it sucks, I know. Hopefully this is just the first of many patches,
and h
On Tue, 28 Jun 2011 18:44:49 +0100, Terin Stock
wrote:
isset() isn't defined for lazy-loading properties, they're either set or
not set.
IMHO lazy-loading is an implementation detail that should not be visible
to isset().
The state you have is "property is there and it has a value, but
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 attemp
On Tue, 28 Jun 2011 07:52:06 +0100, Ivo Võsa 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. __
On Tue, Jun 28, 2011 at 2:52 PM, Ivo Võsa wrote:
> Kornel Lesiński 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 pr
Kornel Lesiński 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
On Sun, 26 Jun 2011 23:36:28 +0100, Terin Stock
wrote:
I've been working with PHPTAL for quite some time, and have always been
annoyed that from within the template an object's __get method was being
ignored. I think I've tracked down the bug (in version 1.2.2, though it
still present i
Marco Pivetta wrote:
Maybe it's just me, but when I have some lazily loaded data I build
__isset() accordingly, otherwise __isset() itself is inconsistent...
We have allready talked about it here, the list didn't like the idea then.
But just as a reminder of my point - __isset() tells you that
Based on my understanding of PHP it seems that __isset() is returning
correctly. At that point in time exampleVariable is not set. Can it be set in
the future? Sure, but it's not currently.
--
#Terin Stock
Undergraduate, Computer Science (CISE), University of Florida
On Monday, June 27, 2011 a
Maybe it's just me, but when I have some lazily loaded data I build
__isset() accordingly, otherwise __isset() itself is inconsistent...
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 27 June 2011 08:25, Terin Stock wrote:
> Normally I can understand that being a stumb
Normally I can understand that being a stumbling block.
The issue here is that my objects lazy-load a sizable amount of the instance
variables, thus the use of __get() to retrieve (or generate) any that haven't
already been set. A few of them are accessed in my controller, but others are
only a
On Mon, Jun 27, 2011 at 6:36 AM, Terin Stock wrote:
> I've been working with PHPTAL for quite some time, and have always been
> annoyed that from within the template an object's __get method was being
> ignored. I think I've tracked down the bug (in version 1.2.2, though it
> still present in trun
I've been working with PHPTAL for quite some time, and have always been
annoyed that from within the template an object's __get method was being
ignored. I think I've tracked down the bug (in version 1.2.2, though it still
present in trunk).
The scenario: an object, exampleObject, implements _
13 matches
Mail list logo
