Re: [FalconJx] state/no state
Hey, I have to admit, after this last week, I am not on my game. My kids finally decided to share what seems to be the flu, although I feel like I am in limbo with really getting sick, so my head and focus is being affected. :) I need to look at what you have done. But, there is a philosophy I have been following with this and it goes; Don't make a dependency between emitting methods HEHE This means, I think state is fine if you are creating it or memoizing the state for calls that happen int the traversing method. It seems like your accessor memory deals with that method every time it's called right? Or are other methods dependent on what you are saving there? Remember the problem we have with the classDefinition and testing a method below a visit method that set that state? We couldn't unit test it. I am a weird person when you met me because I honestly believe in units and that keeping true abstraction by testing units is the only way to save headaches in the future. That being said, can we do things to get it done or should we take a bit more time to find that solution that satisfies the unit approach, which is just good encapsulation. Sorry for all the quotes, just trying to make a point. Anyway, let me look and give you my opinion. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Hi, I'm aware we're trying to keep a state-less thing going with FJx, but I ran into an issue that I'm not sure how to solve without adding some kind of storage (private variable) on the 'goog' emitter. The thing is that a property has/can have both a getter and a setter accessor. For a full 'goog' implementation, in addition to emitting 'Object.defineProperty' for each, we also want to add a property declaration on the prototype, to set the type. We want to add this declaration only once, so my solution is to 'remember' if I already added it in a private variable, since I know of no other way of checking if I have already written something to the output. Am I doing it right? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] state/no state
Quoting Avi Kessner akess...@gmail.com: Uneducated question here. If we can't read what is spit out, how can make tests to make sure that the gestalt is correct? Erik didn't mean we can't read, when emitting all String data is pushed into a Writer buffer. If we can read what is spit out, why not read it and remain stateless? We can, he is saying go back and read what is in the buffer currently, which he could do but would be extremely unwise. I'm assuming that as time goes on, we'll want to read the output to optimize it on some level. No, we optimize when the output is being assembled. Erik; I just looked at the code again and remember, my head is whacked but, instead of recording like you are in the method, I think pre proccessing members in one shot before you loop through each to emit it would be a better approach. My thought is, if in the future you need to pre-proccess any other things before the member emittion, that it's all done in one place and you can have state from that point. Using this, the emit methods will still be dumb, in the fact they will only write out what currently exists. I think I will write something to show you what I mean in a day or two. Mike Mike brought to you by the letters A, V, and I and the number 47 On Sun, Jan 20, 2013 at 1:38 PM, Michael Schmalle apa...@teotigraphix.comwrote: I knew I looked at what you did before. I see no problem with that Erik, if you test visitAcessor() and it does what you want and in the context of the method which is to test the production of a unit where the unit here is a field and Object.defineProperty() so that is good. Does my thinking about state make sense to you with this example? We are trying to avoid crossed wires. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Hi, I'm aware we're trying to keep a state-less thing going with FJx, but I ran into an issue that I'm not sure how to solve without adding some kind of storage (private variable) on the 'goog' emitter. The thing is that a property has/can have both a getter and a setter accessor. For a full 'goog' implementation, in addition to emitting 'Object.defineProperty' for each, we also want to add a property declaration on the prototype, to set the type. We want to add this declaration only once, so my solution is to 'remember' if I already added it in a private variable, since I know of no other way of checking if I have already written something to the output. Am I doing it right? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] state/no state
Mike, I see what you mean, I've added a TODO for me in the Class emitter (where all the members are gathered ;-)) EdB On Sun, Jan 20, 2013 at 1:14 PM, Michael Schmalle apa...@teotigraphix.com wrote: Quoting Avi Kessner akess...@gmail.com: Uneducated question here. If we can't read what is spit out, how can make tests to make sure that the gestalt is correct? Erik didn't mean we can't read, when emitting all String data is pushed into a Writer buffer. If we can read what is spit out, why not read it and remain stateless? We can, he is saying go back and read what is in the buffer currently, which he could do but would be extremely unwise. I'm assuming that as time goes on, we'll want to read the output to optimize it on some level. No, we optimize when the output is being assembled. Erik; I just looked at the code again and remember, my head is whacked but, instead of recording like you are in the method, I think pre proccessing members in one shot before you loop through each to emit it would be a better approach. My thought is, if in the future you need to pre-proccess any other things before the member emittion, that it's all done in one place and you can have state from that point. Using this, the emit methods will still be dumb, in the fact they will only write out what currently exists. I think I will write something to show you what I mean in a day or two. Mike Mike brought to you by the letters A, V, and I and the number 47 On Sun, Jan 20, 2013 at 1:38 PM, Michael Schmalle apa...@teotigraphix.comwrote: I knew I looked at what you did before. I see no problem with that Erik, if you test visitAcessor() and it does what you want and in the context of the method which is to test the production of a unit where the unit here is a field and Object.defineProperty() so that is good. Does my thinking about state make sense to you with this example? We are trying to avoid crossed wires. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Hi, I'm aware we're trying to keep a state-less thing going with FJx, but I ran into an issue that I'm not sure how to solve without adding some kind of storage (private variable) on the 'goog' emitter. The thing is that a property has/can have both a getter and a setter accessor. For a full 'goog' implementation, in addition to emitting 'Object.defineProperty' for each, we also want to add a property declaration on the prototype, to set the type. We want to add this declaration only once, so my solution is to 'remember' if I already added it in a private variable, since I know of no other way of checking if I have already written something to the output. Am I doing it right? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
