[Moose-dev] Re: PetitJava

Hi, I'm not sure what exactly you want out of the visitor pattern. It seems like the current accept.. methods (that aren't either 'TO DO' or #subclassResponsibility, that is) just ask you to #visitNode: or #visitNodes: for the various instance variables in the AST classes. Am I missing something here? I must say that I haven't used the visitor pattern with parsed results before, and am not sure what you want and/or need out of this. As for PrimaryWithSelectorsNode, after looking back at it, I can see that I have obscured what the 'primary' was from when it was parsed out. however, in looking at what could constitute a primary (versus the selectors part), I find myself confused with what answering a primary would be. I could by most anything - for a single item (boolean, literal, variable) to something very complex (such as a string of identifiers hanging off of an identifier with or without message sends on the end). Instead I attempted to simplify it into an array of the parts so that I could iterate over them as needed. sometimes I would like to find the first in the list, sometimes the last, and sometimes I'd like to search the whole list for a specific call (if present) in the middle. so, take the code: this.getCommand().getContext().getUser().getActiveProfile() The current PJPrimaryWithSelectorsNode will have these in the codeList array: this getCommand() getContext() getUser() getActiveProfile() I did change the behaviour of the parsed #primaryWithselectors - previously it would have bundled this and getCommand() together into one unit identified as 'primary' and all of the other methods as an array of 'selectors'. similarly, this code: new SearchUrl(Search.class).set(parm1, p1).set(parm2, params.get2(p2)).set(parm3, p3).getHref() will return the codeList array: new SearchUrl(Search.class) set(parm1, p1) set(parm2, params.get2(p2)) set(parm3, p3).getHref() Previously, it would identify the first item of the array as the primary, and the rest as the selectors. Which does make a lot of sense to me. finally, this code: this.context.getUser().getActiveProfile().getProfileProperties() will return in the code array: this context getUser() getActiveProfile() getProfileProperties() Previously, primary would have consisted of the array this context getUser() while selectors would have been the array of getActiveProfile() getProfileProperties() I should note that I'm not a Java coder myself and am not clear on how Java coders identify the parts of their code. I have tried to mostly follow what was previously there in the parser as it was clearer than what I'd likely come up with. However, I can't really see myself why the 'primary' was primary in the previous examples - is it clear and I should revert back, and have the visitor visit the restored primary and selectors? or should I have the visitor visit each part of the stacked structure that the Java coder has presented us? Which way would you prefer it - I'll modify it to fit your desires. Thanks, Chris On Tue, May 28, 2013 at 10:55 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: HI, I've checked the changes. `acceptPrimaryWithSelectorsNode:` has only a flag so I didn't get how should I accept it and started to check out what the idea is. I still don't get it. It has some code list that is usually an array. Why do we need that node? What code entity does it represent? It looks like instead of building an AST from parsed arrays we are wrapping them in other classes. Yuriy On 28 трав. 2013, at 21:30, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: