* * * * *
“Oh, I see the problem—you're trying to add a pterodactyl to a gluon and you
just can't do that … ”
I spent most of my time at The Office today working on the web-based security
cam for our data center [1]. The actual camera is working fine and the images
are accumulating on a server—the stuff I was working on today involves
browsing the ever accumulating pictures.
The first major decision I had to make (and this is a project I've been
working on for the past couple of weeks) is whether to generate static pages
(as the images are mailed in) or do a completely dynamic site. There are
arguments for both ways; the pages won't change all that much—during the day
only the main index page for the current day, then at midnight the index page
for the current month, then once a month the current page for the year and
while I personally like this idea (a form of early binding if you will) there
are a few downsides: one) it's even more files to store and two) if there's
ever a design change, all the pages will have to be regenerated.
A dynamic site, however, only requires a few additional files for the
program, and changes to the site take effect immediately, but the page(s)
have to be built (and built and built) for each request, which involves quite
a bit of disk I/O (Input/Output) (to get image filenames namely).
I ended up going the dynamic route—Smirk wants to store the images for as
long as possible so the less overhead (in this case, static web pages) the
better. Also, it's not like we have to support heavy network traffic—only
one, maybe two people at a time may be viewing these, and only if there's a
problem with missing tools.
Also, since Smirk is a fan of PHP [2] (Why? I don't know … ) so I figured
this would be a good chance to get a feel for programming in that … language.
I do not like it, Sam I am. I do not like PHP and ham.
The whole global variable thing I'm ambivilent about. PHP is unusual (for the
languages I've used) in that you have to declare which variables are global
every time you use them, like:
> $g_base = "/some/random/path";
>
> function display_file($template)
> {
> global $g_base;
>
> for ($this->m_i = 0 ; $this->m_i < count($this->m_files) ; $this->m_i++)
> load_template($g_base,$template);
> }
>
(why yes, I am using objects in PHP [3], and yes, the looping variable is
part of the current object so I can support templates, but that's not
important right now)
Unlike most languages I've experienced, if you do:
> $g_base = "/some/random/path";
>
> function display_file($template)
> {
> for ($this->m_i = 0 ; $this->m_i < count($this->m_files) ; $this->m_i++)
> load_template(**$g_base**,$template);
> }
>
the language looks first to see if $g_base is defined within the function,
and if not, looks to see if it's been defined outside of the function and if
so, uses that. PHP, on the other hand, will just assume you want a new local
variable named $g_base and not even bother looking elsewhere, hense the need
to declare $g_base as being global within display_file().
Not something I'm used to.
But I can see why it's done that way and can't really argue with it, but I
keep forgetting about that, expecting PHP to handle lexical scoping [4].
I also find the gratuitous use of dollar signs annoying, but at least PHP
uses it in a consistent manner:
> var $scalar;
> var $array = Array();
> var $hash = Array();
>
> $scalar = 0;
> $array[0] = 1;
> $array[1] = 2;
> $hash ['brownies'] = "are good";
> $hash ['hashish'] = "is illegal";
>
unlike Perl, where the declarations of scalars, arrays and hashes use
different symbols:
> my $scalar;
> my @array;
> my %hash;
>
so I would expect Perl to work like:
> $scalar = 0;
> @array[0] = 1;
> @array[1] = 2;
>
> # NOTE---Perl uses {} instead of [] for hashes!
>
> %hash{'brownies'} = "are good";
> %hash{'hashish'} = "is illegal";
>
but nooooooooooooooooooo! It's back to the dollar signs:
> $scalar = 0;
> $array[0] = 1;
> $array[1] = 2;
> $hash{'brownies'} = "are good";
> $hash{'hashish'} = "is illegal";
>
But I come to bury PHP, not Perl.
The biggest sticking point I have with PHP (and I have the same issue with
Perl as well) is the lack of type checking—a variable could be a number, or a
string, or an array, or an associative array (aka hash table) or a
pterodactyl. This means you can do stuff like:
> $fourscore = "80"; //note-this is A STRING
> $seven = 7; //note-this is A NUMBER
> $yearsago = $fourscore + $seven; //Do you get 87 as
> //A STRING or as
> //A NUMBER? It's BOTH!
> //It's Hiesenburg programming!
> //Wheeeeeeeeeee!
>
But something like:
> $bills = Array(); //note-this is AN ARRAY
> $account = 400; //note-this is A NUMBER
> $money = $account - $bills; //What now?
>
will most likely blow up.
At run time.
And while it's clear what's wrong with the code above, it's not quite so
clear in the following:
> $bills = get_the_bills();
> $account = 400;
> $money = $account - $bills;
>
Hope get_the_bills() returns something that can be subtracted from a number.
Or was it sum_the_bills() that returns the number? (certainly
ignore_the_bills() is not the right thing, although that is tempting, and I'm
digressing).
I suppose I'm too used to strongly typed langauges where the compiler nickel
and dimes you to death about types so I don't have to keep all those details
in my head (the computer is more capable of keeping track of details like so
I don't have to).
So I'm having to constantly remind myself that $g_baseobj->m_subobj is a
“month object” (not a “day object”) in this portion of the code, and that
find_entry() returns a number (the index into an array), not the entry itself
(although perhaps I could rename that function find_index() instead … ).
Object support in PHP isn't that bad—certainly nicer than Perl, but again,
the serious lack of type checking makes it difficult to track down problems,
and the error messages it gives could be more informative (“Okay, it's nice
that I didn't call parent::init() with the correct number of parameters, but
which call to parent::init() was incorrect—who or where was the call made
from you XXXXXXX piece of XXXX?”).
It's always nice to know that “PRINT debugging” will always be alive and
well.
[1]
gopher://gopher.conman.org/0Phlog:2005/05/25.1
[2]
http://www.php.net/
[3]
http://www.php.net/manual/en/ref.classobj.php
[4]
http://c2.com/cgi/wiki.pl?LexicalScoping
Email author at
[email protected]