Re: QuickFormController design change idea/request

Hi, Matt Friedman wrote:

What I would looking for would be more of an object oriented solution such as accessing the session via some object interface, rather than a data structure (the $_SESSION array). If the session was handled/accessed by an object then you could switch that object and Quick Form wouldn't know the difference. Accessing the array directly causes a dependency on the array with that name and that structure - overwriting the session array is also probably not the clearest thing to do and probably confusing, because the convention is that the array with the name $_SESSION is specifically for php based sessions.

PHP is not 100% pure object oriented language. Most of its built-in extensions are procedural rather than OO, user input is available in superglobal arrays rather than through some OO interface, etc. Of course you can do OO wrappers around all this, but it is *much* easier and more productive to switch to some other 100% pure OO language. A saner approach is to use builtin functionality wherever it is possible.

With object programming we are trying to hide the data, not expose it to clients. The current way sessions are accessed in Quick Form does just the opposite - it exposes the underlying data structure. Additionally, if I followed your advice I'd have to do some hack like populate my session mechanism and then populate the $_SESSION variable thereby updating data in two different places, something I'm not particularily interested in doing for what should be obvious reasons. Is there no chance of changing the design? I'm hoping I can convince you that this is worthwhile - however, if there isn't interest in changing it let me know as we can work out other solutions. Ideally, Quick Form would extend its already excellent design to apply to this issue. What I mean is the authors have followed front controller design principles nicely for all of the code except for the way sessions are accessed - why not apply this thinking to this issue as well?

Let's see here: there is a number of people (lets call this number M1) using PHP with builtin session handler and not bothering about it, there are M2 people writing their own session handlers and registering them via session_set_save_handler() and there is M3 people who are writing their own session mechanism out of some real (or imagined) necessity. It is also safe to assume that M1 >> M2 >> M3 What's the benefit for M1 + M2 people to have the proposed abstraction? No benefit: their apps just run slower due to loading and running of uneeded code. Also the remaining M3 people may just follow my advice with regards to populating the $_SESSION array. Also H_QF_Controller package is definitely not the place for having a generic session abstraction mechanism. So if you'd like to implement such a mechanism, you'll need to propose a new package for such abstraction. I sincerely doubt this proposal will make it through, though.