PHP Modules?

[nospam@geniegate.com]

Re: PHP Modules? and perl.

gunzip <none@none.co m> wrote:
[color=blue]
> OK, Perl is an all-purpose language so maybe we shouldn't expect it to make
> decisions about its core based on the same criteria as PHP's. I reckon it
> will probably become largely the preserve of sysadmins in the long run, though.[/color]

Well, sysadmins and maybe big ticket n-server stuff. For average joe
with an ISP, perl is pretty much useless for the web side. Larger
companies that for some reason aren't using Java and have access to the
details of the server(s) can still make use of perl'ish stuff. Dedicated
servers are also useful places for perl.

In Average Joe's world, perl is still good for cron jobs or even CGI
scripts, things that aren't really meant to be hit all that often.
(such as a script that creates a tarball of backup files and sends it
across the browser or something) I would never attempt to use PHP as a
cron process except as a last resort.

One thing perl has that I've never really seen in PHP is the
eval { ... }; exception handling stuff.

Wish it were possible (in PHP) to do this:

eval {
something() or die("Failed at something");
something_else( ) or die("Failed at something_else" );
};
if($@){
cleanup_resourc es();
die($@);
}
.. continue ..

or even a try { } catch { }


PHP seems to require a special die handler function and a whole lot of
overhead just to mimic exceptions. (even then, the functions generally
don't die() on a problem, so you have to check the return value.)

Ah well.. I'm kinda deviating from modules here. :-)

Jamie


--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

[gunzip]

Re: PHP Modules? and perl.

nospam@geniegat e.com wrote:
[color=blue]
> One thing perl has that I've never really seen in PHP is the
> eval { ... }; exception handling stuff.
>
> Wish it were possible (in PHP) to do this:
>
> eval {
> something() or die("Failed at something");
> something_else( ) or die("Failed at something_else" );
> };
> if($@){
> cleanup_resourc es();
> die($@);
> }
> .. continue ..
>
> or even a try { } catch { }
>
>
> PHP seems to require a special die handler function and a whole lot of
> overhead just to mimic exceptions. (even then, the functions generally
> don't die() on a problem, so you have to check the return value.)
>
> Ah well.. I'm kinda deviating from modules here. :-)
>
> Jamie
>[/color]

PHP5 has Java-style exception handling (try,catch,fina lly) so you're in luck.

gunzip

[Chung Leong]

Re: PHP Modules? and perl.

<nospam@geniega te.com> wrote in message
news:4PYhc.5147 $w96.721861@att bi_s54...[color=blue]
> gunzip <none@none.co m> wrote:
>
> PHP seems to require a special die handler function and a whole lot of
> overhead just to mimic exceptions. (even then, the functions generally
> don't die() on a problem, so you have to check the return value.)
>[/color]

But is exception handling really necessary in web development? In PHP all
resouces are released when the script terminates, so one of the main reasons
to do exception handling is out.

[nospam@geniegate.com]

Re: PHP Modules? and perl.

Chung Leong <chernyshevsky@ hotmail.com> wrote:[color=blue]
> But is exception handling really necessary in web development? In PHP all
> resouces are released when the script terminates, so one of the main reasons
> to do exception handling is out.[/color]

True, however if one were using a database that supported transactions,
things can get messy checking return values. 90% of the population seems
to be using mysql, so the transaction recovery stuff is a moot point.
(Suppose one could set a function up that rolls back the database when
the script terminates or something, but that seems kind of messy)

Also it's handy to check a "stack" of functions for a problem, based on
the success or failure, do something else.

Imagine: // paranoid file editing.

lock original.txt // writing.
copy original.txt original.tmp // allow .txt to be read while working
process original.tmp // edit working copy.
rename original.txt to original.bak, // incase unlink & move fails later.
rename original.tmp to original.txt // Apply our edits, wish for an
// atomic swap($a,$b) :-)
unlock // dubious probably, depends on lock strategy.
unlink original.bak // cleanup.

Any of these steps fail and you might have temporary files lying about
that should be cleaned up. Exceptions are nice for this type of problem.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX