Hi

On Sun, Jun 30, 2013 at 7:24 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

Now the thing about the PetitJava. I see the parsed Java AST as wrapped expressions. This way type cast wraps expression that is casts into some type, negation expression wraps an expression that is negates. Chris sees it as properties for example accessor node has a property for cast and a flag for negation. Also in his vision a node should store an array of accessors if they follow each other whereas I say that there should be a couple of nodes wrapping each other. Also I think that code should be refactored as right now accessor node has negation flag with getters and setters, same is defined for method invocation. This functionality should be moved into a common superclass, same should be applied for type cast etc... Also it's a bit frustrating that one node can be created as a result of parsing several different grammar entities (you can read my full impression in previous PetitJava discussion).
Thank you for writing this. It confirms to me that you do understand my position - mostly. šI have attempted to remove the array of accessors from the AST nodes that I've added - these should be no nodes left like that (with an array of accessors or method invocations). šInstead, each accessor or method invocation should have a 'receiver' that is is relative too, and it knows about nothing further up or down the chain.

I don't think that the negation flag should be moved up the chain - from what I can tell (and I admit, unfortunately, that I am not a Java expert of any kind) is that the Java specifications do not consider variable accessors and method invocations as the same thing - rather, quite a bit different. šhence the reason the negation flag was placed into two different trees by me.

That said, you did a good job of summarizing where we differ on this topic.
š
It's fine that we have different views on the development as we can develop two different things. But if we want to have one project in Moose platform, other members of community should help to decide what we are developing.
I agree with this, too.

As Stephen guessed below, I have no opposition to the very detailed AST model. šThat said, I definitely don't have the personal drive to build it (that spec is huge!), and I'm sure my employer would not willingly pay for me to finish it, either. But, I would definitely like a more robust AST model - either where I have started, or where you or the community wants to go.

Thanks,
Chris
š
Uko

îÁĦÓÌÁÎÏ Ú iPhone

30 ÞÅÒ×. 2013 Ï 15:43 Tudor Girba <tudor@tudorgirba.com> ÎÁÐÉÓÁ×(ÌÁ):

I missed that mail :).šI could not keep up with what was happening with PetitJava during my holidays, but I certainly think it is a piece that people care about (at least from a user point of view). Your and Chris's efforts are certainly appreciated.

In any case, I am not sure I understand why you think that PetitJava is really the problem given that the petitjava build is green. Could you elaborate?

Cheers,
Doru


On Sun, Jun 30, 2013 at 12:41 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Yeah, I know, and I already told about it week ago when PetitJava was merged. Looks like no one cares about the emails that I send about PetitJava, but I want FAST to stay green and evolve. So most likely when I will return from the vacation tomorrow I'll make a fork and will depend on it.

Uko

îÁĦÓÌÁÎÏ Ú iPhone

30 ÞÅÒ×. 2013 Ï 12:11 Tudor Girba <tudor@tudorgirba.com> ÎÁÐÉÓÁ×(ÌÁ):

Hi,

The FAST job is broken since a week:

Please take a look at the problems.

Cheers,
Doru

--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev




--

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev