NYCPHP Meetup

[Michael B Allen]

On 9/27/07, Jon Baer <jonbaer at jonbaer.com> wrote:
> Do many here use the SPL library?
>
> I could never really understand this "library", on one side part of the Java
> programming that I really felt to be a burden of added / bloated code was
> the idea of the "Iterator" (you always had to grab one) and that is pretty
> much what the SPL is (for PHP5), and part of the joy to PHP was the ease +
> use of a foreach loop and then Java took a step back and implemented the
> same foreach idea in current JVMs but I barely see it used in many projects.
>  I would guess that Java people coming to PHP would understand it's uses /
> design pattern better

I did Java for many years. Now I do mostly C. But at the moment I've
been digging around inside Zend Framework. So I think I can add a few
opinions about this topic.

Whenever the topic of OOP comes up I can't help but wonder if they're
just enthusiastic about just having read Design Patterns or if they
really understand that OOP is just a tool that has certain use
scenarios.

It seems that a lot of people think that if a language supports OOP
that they should always use it as if it were "better" than not using
OOP. That is false.

For example, I did a network protocol client in Java that was
basically a lot of encoding and decoding of binary blobs and
multiplexing I/O and so on. Because Java's libraries required OOP
(unlike C++ which is backward compatible with straight C) it was
actually harder to write networking code. Aside from occasionally
using inheritance to do simple things like represent similar packet
formats, Java just got in the way. In some cases libraries were so
bloated and overdesigned we simply couldn't use them (even though they
were specifically designed for doing network programming (e.g. nio and
concurrency packages)).

OOP provides one major benefit - polymorphism. If you don't need
polymorphism, you should not be using OOP. But in some cases
polymorphism can make your code very simple and yet highly extensible.
It *can* be extremely powerful.

I don't know anything about SPL but if it doesn't make any difference
to use foreach instead of an Iterator then obviously you should use
foreach. But if it is desirable to allow users to redefine how the
behavior of the iteration works, then an Iterator class may be
appropriate.

> but the part of the Zend article I don't understand is
> ...
>
>
> "This library of interfaces creates a standard API for certain kinds of
> built-in functionality, allowing your classes to interact with the PHP
> engine in a much more seamless manner."

One of the more powerful use cases for polymorphism (and thus OOP
capabilities of the language being used) are frameworks. Frameworks
are by definition supposed to be extensible so the benefits of using
OOP can far out weigh the overhead of using it.

Currently I am writing Zend_Auth_Adapter classes for Kerberos
authentication (SPNEGO for SSO and vanilla Kerberos for the login
form) and a Zend_Controller plugin. With the Zend_Controller plugin
users will be able to tweak their bootstrap file and add Kerberos SSO
and a Kerberos login form without modifying the underlying code.

As for Zend Framework itself, my first impression is that it's
actually pretty well thought out. I've done a number of auth plugins
for various PHP apps the trend is to over-abstract the authentication
process. I'm very pleased to say that ZF did not do this. The
Zend_Auth_Adapter interface has one method 'authenticate()' and avoids
the common mistake of trying to manage and automatically persist
credentials.

The other ZF component I have experience with is Zend_Controller and
again, despite my reservations about OOP, it is not over-designed.
Sure there's overhead in creating all of those objects and resolving
methods but you do get significant flexibility in return. And another
thing that should not be overlooked is that that flexibility ensures
that there will be a heathy community which provides the operator with
invaluable support.

I predict that Zend Framework will be quite popular.

Mike