NYCPHP Meetup

[Hans Zaunere]

> i wasn't posting about my scripts.  i already write my scripts for
> safe_mode
> and the PHP 4.2.x default settings (with some stricter settings too, like,
> uh, safe_mode).  i was asking about other scripts, lots of which can
> be downloaded, and none of which (of the not so many, but n>5 i've tested 
> so far) will run unmodified with the settings mentioned above.

While there are exceptions, generally a well-written application will:

1) Set it's environment explicitly, through ini_set() for example.
2) Document what it's environment requirements are.
3) Allow for a configuration process, where the application adjusts to your
environment.
4) Perform runtime checks that changes program-flow, etc.

While none of these are perfect, in such a hetergenous environment that PHP
is often required to work in, they are needed.  If a script can't adjust to
it's environment (and it's meant as an end-user program, for distribution)
don't use it - or, help the developers perfect their application.  The bar
needs to be raised, and tolerance of rinky-dink scripts needs to be
decreased.

> is there even an understanding in the PHP world that there might be a
> problem with the current situation and that a solution is needed?

Yes and no, but the 'current situation' is broad.  Well written applications
generally can work in an assortment of environments, and will allow for
configuration, which is always nessecary (otherwise we'd be out of work). 
But again, you should not bend over backwards to support callow scripts.

> either
> that or perl will win.  as i noted, i've got bugzilla (royal pain that it
> is
> to install notwithstanding) running.  and i have not got a single PHP
> bugtracking system running correctly yet (mainly because of the
> register_globals requirement, they were written for 3.x, 4.0.x etc).

register_globals will be something that haunts PHP for some time.  I suggest
not using applications that depend on register_globals, and if so inclined,
offer patches to the developers, so that we can rid ourselves of this
tomfoolery.

> there *is* a similarity, i agree. PHP was just easier for me since it
> looks so much more like C.  i can't stand the line noise that some
> perl looks like.  but that's just me.

No it's not.

All this said, PHP could use a general standard, or best-practice spec. to
increase portability.  This has come up on the list before, but as always,
there aren't enough hours in the day.



=====
Hans Zaunere
New York PHP
http://nyphp.org
hans at nyphp.org