Many of you will just switch off because it's me spouting off again, but
hopefully some of you will listen ...
The current discussion on http response objects and other aspects of the
transmission process has brought out a few more 'what the ...' from some
of you and as with a lot of the 'modern' discussions, the reasons for
wanting something tend to be wrapped in a lot of assumptions that the
rest of us understand exactly what is being discussed. In many cases
I'll be frank - despite starting programming back in the early 1970's
much of the debate goes over my head!
'http response objects' ... When I switched to using PHP over C/C++ we
had something called prettyURL which the apache rewrite rules processed
into a format the PHP would handle. Nowadays it is something like
'RESTFUL design' that is doing the same process? My own style of working
is for modular software. It started when the tikiwiki code base was
ported over to tikipro and rather than one humongous pile of code, each
'package' of functionality has it's own directory of specific code and
uses the central core of common code. The url's have /wiki/, /contact/,
/nlpg/ and the like and if a client needs a different style of contact,
enquiry or task process it can be handled in isolation. Why is this
relevant to the current discussion? Because it seems at odds with the
basic way php-fig is designed with it's drive to centralization and when
I've tried to apply their rules to my own code base it simply does not
work. And wiping my neatly tab indented code is never going to convince
me that THAT dictate is universally acceptable! Tabbed indenting goes
far back even into Algol days and while the rules for C/C++ even in the
PHP code base is TAB I'm not going to start being selective elsewhere!
So I've not bothered even following the later PSR rules since simply
starting adds hours to any code rework and I STILL have a lot of code
which I've not found any help to automatically translate to clean (still
5.4 at this stage!) code.
Moving forward, handling cookies seems to be another area where while
some people feel they should be expunged from the internet, there is not
a suitable alternative when handling the state of an anonymous visit?
Nothing in the http traffic can be relied on to identify the visitor
with even ip address changing from request too request, so we need to
pass something back that can at least identify the client on subsequent
requests?
This is the area where traffic back and forth could perhaps be tidied
up, but the question I still see no answer to is "Just what is it people
think is broken and needs fixing?" With the current discussions on
switching to a 'restful' interface to the TZDIST data, I can see that
providing PHP with a cleaner way of using that format may be an
advantage, but I don't see why one would move what is intended to be
pure static content back into PHP? Once the package of data has been
generated, it is cached at the http layer and modern tools like nginx
handle it, only passing back to PHP when dynamic additions are required?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
The current discussion on http response objects and other aspects of the
transmission process has brought out a few more 'what the ...' from some
of you and as with a lot of the 'modern' discussions, the reasons for
wanting something tend to be wrapped in a lot of assumptions that the
rest of us understand exactly what is being discussed. In many cases
I'll be frank - despite starting programming back in the early 1970's
much of the debate goes over my head!
I think there's a good point here, that we need to make sure -
particularly in the core of the language - that we maintain PHP's
long-standing support for writing quick, unstructured programs, without
a lot of boilerplate.
Ideally, new use-cases which are difficult or awkward with current
functions would be supported by simply adding new functions in the same
style as those that already exist. However, PHP's standard library of
functions is notoriously inconsistent, so the right way to add such new
functionality isn't always obvious, and sometimes doing so would just
add to existing confusion or complexity. In such circumstances, it is
sometimes right that we look at designing a new API which overlaps with
the old; if this can be done in such a way that the new API is still
simple for the simple cases, all the better, but if not, the old API
needs to be maintained as more than just a begrudging compatibility shim.
The superglobals for HTTP requests are probably a good example of this:
we definitely need to keep them for compatibility reasons, but further
than that we mustn't start thinking of them as inferior or deprecated if
their replacement requires an additional 10 lines of boilerplate to be
added to every 1-page PHP script.
As for PHP-FIG, its mission is rather different - for those people who
are writing framework-based applications, and modules designed to be
used by those applications, it is useful to have a set of agreed
conventions ("Recommendations") to work with. Some of these are
basically just arbitrary choices, like agreeing whitespace conventions
so that code shared from one project to another doesn't look out of
place. Others can be useful even for smaller projects - for instance, if
you intend to pass around a logger object, you can make it implement
PSR-3, making it trivial to switch over to a third-party library like
Monolog if you later decide that would be beneficial.
--
Rowan Collins
[IMSoP]