Roman Neuhauser wrote:
...
>
> You'll have to change the code. I'm suggesting a nice clean way that'll
> not only conform to the probable rules of PHP 6 (which are not specific
> to PHP, at least static is not), but that'll also conform to the rules
> of good design. You're saying the changes are superfluous. Ok then,
> but what do you really want? I'm fine with you just griping, if it's
> labeled as such.
I just want it to keep working - the code began life in Nov 2003, when php5
was still in beta3 ... I'm all for writing better code but *having* to fix something
that works bites.
>
>>> I wouldn't do it that way. A single class should not be a database
>>> driver *and* manage connections.
>> fair enough, although personally I find that going a bit far, I don't
>> see the win in splitting up the 'driver' and 'connection manager'. not
>> that this is the problem in this case.
>
> You wouldn't be having this upgrade problem if static DB::query(...)
> wasn't there, and it's there because class DB is a client library *and*
> a connection manager. So I'd say this design mistake (and the fact that
> PHP allowed you to have almostatic methods) are the problem in this case.
>
I might plead with internals for: ;-)
class DB {
almostatic function query() { /*existence of $this is MY problem */ }
}
though I can't see atm how the connection management is the problem,
I assume you think this because of the way connection ids and transaction ids in
ibase are interchangable.
regardless I have a problem, I'll keep looking at the code until a clean solution
presents itself, it's in/out there somewhere.
>> I could easily split out the actual connection management into a
>> seperate object but I'd still be stuck with the problem described
>> above (which is not actually related to connection management).
>
> Not if you make the separation visible to the client code, which, as you
I don't follow you here. could you try an explain it in idiot language? :-P
> write below, is actually only a fraction of those "10000's of lines of code".
>
>>> Do those 10000's of lines of code concern you? rlynch says indirection
>>> and separation of concerns are useless, you either have decent
>>> programmers and global search & replace, or you don't.
>> yes & no. I don't have an endless budget or legions of world-class
>> analysts, designers and programmers at my disposal for building
>> megabucks codebases that implement near-on perfect loosely-coupled
>> application designs, and I don't have the same legion to do search and
>> replace.
>
> I'm at a complete loss then. Richard, what would you advise to someone
> in such a messy situation?
my advice to myself is "find a way to fix it, and then do it" - not sure
what exactly that means in terms of design or code but I figure that has to be
an answer/solution somewhere :-)
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
