Looks like they finally gave in them, but of course that would confine the PHP target to PHP 5.3. When I looked at dong what you propose below, there were problems with variable scope I think, which means you have to duplicate the cleanup code in the catch. Then, you cannot just rethrow e as that isn't what the rule does, so you need a state variable to gate the cleanup code in some circumstances or duplicate the code. I seem to remember thinking that there was a way around it all but that it did end up being a little hard to see when trying to read it.
Jim From: Sidharth Kuruvila [mailto:[email protected]] Sent: Wednesday, October 07, 2009 9:44 AM To: Jim Idle Cc: [email protected] Subject: Re: [antlr-dev] PHP module vs. native runtime Hi, You can get away with something like try{ exceptionalCode() }catch(Exception $e){ doCleanupStuff() throw $e } doCleanupStuff() Php 5.3 does have a goto command, possibly for codegen. Regards Sidharth On Wed, Oct 7, 2009 at 9:48 PM, Jim Idle <[email protected]> wrote: I did think about this, but the main issue is that PHP does not support try..catch..finally and the PHP guys refuse to implement goto (which in my opinion is a little over-zealous, despite the fact that any sensible programmer would not use goto except in exceptional circumstances. It means that generating PHP as a target is likely impossible without a lot of convoluted messing around or producing a version of PHP that has a goto in it. If you have to wrap the C runtime in PHP and then generate C and wrap it in PHP then you might as well just call the C version anyway ;-) Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Geoff Speicher > Sent: Wednesday, October 07, 2009 9:02 AM > To: [email protected] > Subject: [antlr-dev] PHP module vs. native runtime > > I see there is a native runtime for PHP in the works. > > Has there ever been any discussion as to whether it would make > sense, as an alternative to a native PHP runtime, to wrap the > existing C (or C++) ANTLR runtime into a PHP module? In theory, > this should provide a fast PHP target, without the work of having > to write and maintain a separate PHP runtime. > > This is something that I am interested in doing in the near term > unless someone knows of a reason why it wouldn't work. > > Geoff > > _______________________________________________ > antlr-dev mailing list > [email protected] > http://www.antlr.org/mailman/listinfo/antlr-dev _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev -- I am but a man.
_______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
