NYCPHP Meetup

[David Sklar]

 David Mintz wrote:
>
> Suppose -- just hypothetically -- I write a shell script that greps
> the ps output for a user-specified string. I could say, here's my
> shell script and you're welcome to use it, but it depends on ps and
> grep being installed on your system. Is it not a good shell script?
> Should it have its own ps and grep functionality built in,
> independently?

Aside from the suggestions others made about being able to drop in new
versions of ps and grep for flexibility, I'll point out that ps, grep, and
whatever shell your script is written for *do* have dependencies, e.g. libc.
They don't each include their own I/O routines, signal handling, memory
management, etc.

I think part of the difficulty with this discussion w/r/t PHP is the fuzzy
line the core PHP distribution provides between traditional language
features and added functionality (i.e. there is setcookie() so you don't
have to make your own cookie headers with header(), but you can't write new
cookies to $_COOKIE like you can create new session variables by writing to
$_SESSION; or even the fact that there is a bundledd session module) and the
competing standards for add-on frameworks that handle a set (itself fuzzily
defined) of "standard" web programming tasks like form handling, error
management, templating, and so on.

Which flows nicely into what Hans wrote:

> I think it's key to cut a distinction between code reuse, modularity,
> and frameworks.
>
> PEAR is a framework.  Just as in a house, if a load-bearing beam
> is removed, the structure will crumble.  This is the typical
> architecture of a framework.

PHP doesn't provide everything you need for a web framework (IMHO there are
good arguments for and against this) so there are various possible
frameworks out there. For most projects, I think that the benefit of
choosing something widely known and good enough far outweighs the potential
speed or customization benefits from writing your own.

David