Just my 2c here.
The RAII pattern applies to PhP just as in C++. In general you do not need
doCleanupStuff() calls.
So this is typically what should go on:
function name() {
$toCleanupBeforeReturn = new Cleanup(); // Cleanup class destuctor will
be called when flow exits function scope.
try {
$toCleanupBeforeCatch = new CleanupCatch(); // CleanupCatch class
destuctor will be called when flow exits the try scope.
exceptionalCode()
} catch(Exception $e){
// Handle exception here (no cleanup required)
throw $e
}
}
Claude
On Wed, Oct 7, 2009 at 2:00 PM, Jim Idle <[email protected]> wrote:
> 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
>
>
--
Claude Quézel
NOTE: This e-mail message is intended only for the named recipient(s) above
and may contain information that is privileged, confidential and/or exempt
from disclosure under applicable law. If you have received this message in
error, or are not the named recipient(s), please immediately notify the
sender by return e-mail and delete this message. Unauthorized publication,
use, dissemination, forwarding, printing or copying of this e-mail and its
associated attachments is strictly prohibited.
_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org/mailman/listinfo/antlr-dev
