Re: Json.php

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux