Okay, great.   First of all, go get some sleep!

Okay, somewhere in the vicinity of “June 20, 2014” in your particular time-zone, let us continue . . .   (No fair peeking ... go back to bed.)

The key difference between the PHP approach to things, versus (shall we say ...) the Perl approach to similar things, is that PHP programs take-for-granted a very large “global implied-context.” That is to say, the entirety of the PHP interpreter, however it may have been pre-compiled to be (in all of its glorious multiple-megabytes ...) at the time that it was installed on this particular system.   Thus, all of PHP’s mechanisms are based upon simple subroutine-calls, all of which are presumed to modify this one, always-implied, always-interpreter -level “implied context.”   Mind you, there is nothing implicitly wrong with that!   However, Perl’s design-approach is not the same.   And, one very-key reason is that “PHP can more-or-less presume that it is being used by a web-server,” whereas Perl by-design cannot.

The Perl language is equally comfortable doing “web pages” and “seriously-funky DNA-genome twiddling.”   Therefore, the core language-interpreter is extremely small, and the system very-heavily relies upon the notion of useing things, and each of those (sometimes, very-substantial ...) packages that you might use customarily rely upon “Perl objects.” Instead of relying upon any “global context” whatsoever, as PHP by-its-design can do, they rely upon self-describing objects which incorporate all of the necessary per-instance context within themselves.

This architecture enables many things which PHP’s by-design architecture would not readily permit, such as “validating two different strings against two different SSL-keys at the same time.”   PHP’s one-and-only available architecture is strictly a global one.   (No harm, no foul ... it is a perfectly-sensible therefore perfectly-defensible position.)   Perl, on the other hand, chooses to incorporate all of that contextual information into an object.   All of the necessary “magic” is “magically” incorporated into the system by means of use, and the perlguts of “exactly how the trick was done” are delicately concealed from view.

The key difference between the two, then, is simply this:   whereas the PHP interpreter absorbs all of the necessary data-structures into an out-of-sight “global context,” and builds all of the available functionality directly into the php executable at compile-time, by very-legitimate design, the perl executable by-design does neither.   Any “contextual” information, instead of being hidden “somewhere in the guts of” the language-system, will be encapsulated in a programming-language object.   And, all of the functionality needed to use it, instead of being buried in the at-compile-time process, will be fully and dynamically exposed.

Here are two entirely-different (yet, equally-valid ...) approaches to the self-same business task.   Like I said, get some sleep . . .