sphoof proposal: (even) less coupling

[Berry Langerak]

Rationale
---------

Hi. I've been having doubts when it comes to the current architecture
of
sphoof, or at least, the organisation of files and classes. You see,
although I
feel proud of what we have accomplished so far, I think sphoof would
greatly
benefit by becoming simpler or even more loosely coupled. If someone
were to
ask me what sphoof is, I'd have to say it's a framework. Now, that's
not a bad
thing in itself, but I think we shouldn't be profiling sphoof as "just
another
framework".

Now, the point I want to reach with sphoof is a combination of a
component
library and a framework written on top of that library. This entails
creating
(or rather refactoring) to self-sufficient components, which can be
used
solely. That also means that every component has it's own
documentation, which
makes it incredible easy to learn how to use that single component.

I'd also like to have components with rather strict boundaries: they
should be
extremely focussed on one task, and one task alone. They should do all
to much,
and should depend on other classes to do their dirty work for them.
True, most
of sphoof is already built using that philosophy, but I think it could
be
improved still.

By keeping the components very focussed on doing one thing, and one
thing
alone, and by making sure the boundaries are well defined, it should
become
very simple to use a component from sphoof with another library, such
as
Zend_View, or even Smarty, if someone wants that. We're not making
decisions,
we're simply providing a way to do a specific thing in an organised
way. This
is not a new train of thought: Unix has been doing this since... well,
forever.
By combining tools, you can get an extremely powerful whole. If one of
the
tools doesn't work well for your specific situation, you can simple
swap it
out. That's not as easy as it can (should?) be with sphoof, in it's
current
state.

But. I think it's safe to assume that everyone who reads this is
already using
sphoof to write applications, be it on the job or in a personal
project. If you
have used sphoof, it's also safe to assume that you've liked the
"speed" the
framework as a whole can give you. Obviously, I have, and I wouldn't
like that
being destroyed, at all. Therefore, I suggest there is another
component: the
framework component. It simply sets defaults, fills in the blanks by
coupling
sphoof's components together and making it very easy to start writing
apps with
all of sphoof. If you'd like to swap out one single component, that
should be
possible as well.

In conclusion: the rationale is that frameworks tend to be either too
rigid, or
too complex. We can solve this by separating the framework behaviour
from the
reusable components.


Implementation
--------------

Going on a limb here, but I'm thinking it won't be all too difficult
to
refactor sphoof to accomplish the goals mentioned above. We already
have our
components (controller, http, view, etc., etc.), so all that has to be
done is
checking the boundaries and refactoring out everywhere there is a
decision
being made into a separate class.

When using the "glue" (of "framework", or "the one ring") component,
it should
be possible to use the default names of the classes defined in each
component.
That would - sorry Taco - mean that the implementation would greatly
benefit
from using namespaces. While create the framework component, it might
help to
have closures to implement some of the component's coupling.

Therefore, part of the suggestion is to ditch pre-5.3 support,
although I can
imagine some people are not willing to do so. However, 5.3 is the
future, and
say what you wish, you will have to make a transition someday. It also
helps in
development, so why not make the transition right now?


That all said and done, I would like to know two things from you:
first, do you
agree on the philosophy that having many components will add to the
usability
of sphoof, partially or as a whole? If so, which components do you
see? When
we're done with naming the concrete components we have, we can
determine what
the components should look like.

Also, I'd like to hear if you have compelling reasons not to make a
transition
to php 5.3. Thanks for your thoughts in advance, and a bloody happy
new year,
hopefully 2011 will be the year sphoof hits the main-stream. (-:

Cheers,

Berry.