On 1/11/2013 5:43 AM, Amos Jeffries wrote:

Sure, but you coded in that patch a whole bunch of fetch rules which all
said:  if a request was present, use its storeId, if none was present
use the alternative variable storeId.

All I was asking for was to take that piece of logic decision which was
repeated in a handful of places (with slightly different boolean tests)
and make a inline accessor function which anybody can call without
needing to reasearch the diferentce between the HttpReqeust:storeId and
the alternative one, or to re-code the test logic themselves. We should
be able to just call storeId() accessor from the state object and get
whatever the current storeId is. No complex conditionals.

Amos

Got you now.

I am a bit busy right now and I don't even have enough time to fix the minor issues. The different Boolean tests was a mistake and I unified them all into one test.

I do understand what you are saying about using a simple accessor.
It will just take more time for me.

I will try to sit on it again this week and I will reconsider all the mentioned issues in the thread. What I didn't understood is that "state object" which I am not sure what you meant(pointer to the code?). Sorry.

I saw your inline example which is perfect.

I will get into the irc dev channel this week while working on the code.


Thanks again,
Eliezer

Reply via email to