On Fri, May 31, 2013 at 5:04 AM, Yuriy Tymchuk <[hidden email]> wrote:

On 31 трав. 2013, at 14:09, "Tudor Girba-2 [via moose-dev]" <[hidden email]> wrote:

Hi,

On Fri, May 31, 2013 at 12:20 PM, Yuriy Tymchuk <<a href="x-msg://609/user/SendEmail.jtp?type=node&node=4027627&i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote:

Yes, so we both agree on the last part of your message that visiting methods
of the general visitor should visit contents of the node it accepts.

Now second thing is about the method names. It makes sense that visitors
visit and nodes accept. But I think that we should change that once and for
all through all system.

Yes, it would be good. But, for that to happen, we should start somewhere. So, let's just start with PetitJava :)

And then there is still and open question: "should we model AST as method
invocation that has a receiver that is method invocation itself etc… or we
should put that all into a node that is actually an Array wrapper?"

I do not understand the question. Can you provide more info?

Sure.

So Chris introduced a new AST node PJPrimaryWithSelectorsNode that has and array attribute called codeList and when you parse a code like: this.getCommand().getContext().getUser().getActiveProfile() a PJPrimaryWithSelectorsNode is created and codeList is filled with:

this, getCommand(), getContext(), getUser(), getActiveProfile().

Now I tell that is you parse this.getCommand().getContext().getUser().getActiveProfile() a method invocation is created. It has a selector "getActiveProfile" it has no parameters and it's invoked on this.getCommand().getContext().getUser() that is one more method invocation node.

Uko, I like this idea a lot - certainly better than sticking with PrimaryWithSelectors, and better than my array. I'll instead have #primaryWithselectors build AST nodes called PJMethodInvocationNode (or PJVariableAccessorNode for variable access such as this.context) and have the receiver on the methodInvocation be, potentially, another method invocation that may recurse a while (3 times in this example). I think that actually represents what's going on much more clearly.

And, unless you get to it first, I'll also make the visitor changes that Doru suggested. I'll work on that this weekend - if you'd like to go a different way (or are already doing some of this), let me know.

-Chris

As we are 2 persons with different ideas, I posted this on the Moose-dev list, so more people can debate on how do we define AST.

Uko

Cheers,

Doru

Cheers.
Uko

--
View this message in context: http://moose-dev.97923.n3.nabble.com/Re-PetitJava-tp4027589p4027625.html
Sent from the moose-dev mailing list archive at Nabble.com.

_______________________________________________
Moose-dev mailing list
<a href="x-msg://609/user/SendEmail.jtp?type=node&node=4027627&i=1" target="_top" rel="nofollow" link="external">[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
<a href="x-msg://609/user/SendEmail.jtp?type=node&node=4027627&i=2" target="_top" rel="nofollow" link="external">[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

If you reply to this email, your message will be added to the discussion below:
http://moose-dev.97923.n3.nabble.com/Re-PetitJava-tp4027589p4027627.html

To unsubscribe from Re: PetitJava, click here.
NAML

View this message in context: Re: PetitJava

Sent from the moose-dev mailing list archive at Nabble.com.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

If you reply to this email, your message will be added to the discussion below:

http://moose-dev.97923.n3.nabble.com/Re-PetitJava-tp4027589p4027639.html

To unsubscribe from Re: PetitJava, click here.
NAML