Hi. To avoid compatibility issues when people use v4 in applications that already use v3, I'm moving the package to
org.antlr.v4.* as I mentioned recently. this is consistent with org.stringtemplate.v4.* Further, I'm going to implement a new cogeneration and analysis mechanism for v4. I'm going to take the opportunity to fix a number of issues and add all of those features on the wish list. That said, I cannot expect all target developers to simply throw out what they have and start using the new code generation mechanism. When I went out the gate with v4, I be standing there swinging in the breeze with the Java target all of myself. ;) Well, Sam's C# would be there. Anyway, I'm going to graft the new mechanisms onto the v3 code base. In this way, people using targets other than Java/C# can upgrade to v4, which gives them access to the left recursion support and so on. In fact, they will be 100% backward compatible since it will secretly be the exact same code internally ;) This has been an interesting lesson in software evolution. Ok, so how do I manage the legacy code base with all of the new, and very similar, classes? I think I'm going to move the old code base to org.antlr.v3.analysis org.antlr.v3.codegen ... Because of the v3 package name, this new variant won't clash with any other dialect <= ANTLR 3.4 whose jar might be included in an application. The new v4 mechanism will be org.antlr.v4.analysis org.antlr.v4.codegen ... That will physically keep them separated, but the actual class names will collide such as Grammar and Rule. I think that I will prefix all of the previous classes with v3, like v3Grammar and v3Rule. That should make it obvious in the code when they are referenced together and should prevent me mistakenly using the wrong class. For example, the Tool class will need to reference both. If you use "-language Java", it will execute v4 stuff else it will execute v3 stuff. I guess I will have to write a script because there are probably 70 classes. Other than the misc package, there is very little codesharing I can do between the legacy and v4 beyond cut-and-paste. Hmm... maybe I will start out leaving the class names the same and see if the development environment lets me get confused. :) Oh, the runtime for the Java target will be org.antlr.v4.runtime.* Because so many people use ANTLR via maven, I'm going to leave the directory structure compatible with that system. I will also build an ANT script. I will try all of this out in my development branch, but after we release 3.4 from antlr3-main branch, the Main line will morph to the new structure. Any comments? Ter _______________________________________________ antlr-dev mailing list antlr-dev@antlr.org http://www.antlr.org/mailman/listinfo/antlr-dev
