Hi Mark, sure you can ask and I will give an answer as well :)
We started with ANTLR because we wanted to separate the syntactical parsing (done with ANTLR) from the semantical parsing. So the idea was to just parse something like "odata identifier" and evaluate later if this identifier is an entity set or something else. Yet we discovered that in order to perform such syntactical parsing one needs to know the semantical knowledge of the previous and current segment segment. So for example ES(1)/NavProp(2) is only possible if the first segment ES is really an entity set or a function import which delivers a collection. And the brackets with key is only allowed if you really have a navigation property that results in a collection. So we were at a point where we needed this information so we had to implement the visitor. There you have to keep a stack of information at hand since each method gets called not by you but by the ANTLR framework. This lead to much confusion for supportability. Additionally we wanted to reuse the grammar file for the filter parsing. Yet this required nearly similar code covered with if statements which would do nearly the same for filter and resource path parsing but not yet quite the same. In my opinion this polluted the code. So all in all the reasons to use ANTLR were getting smaller and smaller and so we started the refactoring. As a bonus the new parser seems to be faster than before. Best Regards, Christian -----Original Message----- From: Mark Stafford [mailto:[email protected]] Sent: Montag, 11. Januar 2016 03:09 To: [email protected] Subject: RE: Merge of the UriParser branch Can I ask why you wanted to get rid of the ANTLR dependency? It's something we've looked at from time to time, so it's interesting to us that you're trying to move away from it. -----Original Message----- From: mibo [mailto:[email protected]] Sent: Sunday, January 10, 2016 3:36 PM To: [email protected] Subject: Re: Merge of the UriParser branch Hi, From my side the decision to replace the ANTLR based parser with an own implementation was good and it is nice to see the result on the feature branch. After a look into I give a „+1“ for merge the feature branch (OLINGO-834_Filter_Parser ) into the master. Best Regards, Michael > On Jan 8, 2016, at 2:45 PM, Amend, Christian <[email protected]> wrote: > > > Hi, > > > There has been some refactoring going on for the URI parser on this branch: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit-wip-us.apache.org%2frepos%2fasf%3fp%3dolingo-odata4.git%3ba%3dshortlog%3bh%3drefs%2fheads%2fOLINGO-834_Filter_Parser&data=01%7c01%7cmastaffo%40microsoft.com%7c9df1dc6a095549bc3c8a08d31990aff7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vXuNpFkt4GYoFUy38uLLHVPy1MiYhLz%2fHG6YI%2ff%2biWc%3d > > > The goal was to get rid of the ANTLR dependencies which was achieved. All > previous tests are running smoothly but I wanted to give the community a > chance to give feedback if you like since this is a rather large change. > If there are no objections I would merge the code into the master branch on > Monday next week. > > > Afterwards we can work on the other open URI parser issue which was opened in > our JIRA: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fOLINGO-846&data=01%7c01%7cmastaffo%40microsoft.com%7c9df1dc6a095549bc3c8a08d31990aff7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZpGJLjiVyBMxDLyRQgiAbeR3tgcz6NIRncme4SvXAjE%3d > > > Best Regards, > Christian >
