# [EMAIL PROTECTED] / 2007-04-19 02:19:14 +0200: > Roman Neuhauser wrote: > > # [EMAIL PROTECTED] / 2007-04-18 11:54:59 +0200: > >> but a practical question for you Roman (seeing as your very much > >> into OOP), > > > > I'm not very much into OOP, I'm very much into programming techniques > > that allow me to limit the number of balls I need to keep in the air > > at any given moment, and to write code that is less likely to contain > > bugs, is easier to understand, more flexible, and takes fewer lines. > > sure, I wasn't trying to offend! - in practice much of what you have > shown here (alot of interesting stuff) has been OOP code.
No offense taken, that was just to clarify that I'm not an OOP devotee. But try a bit of functional programming in a language like PHP without objects. ;) > >> how would you write a single method that could be called statically > >> or not so that one can transparently use the same method to do > >> stuff in different contexts? > > > > I would not. > > not helpful. the method in question exists and works. Except it got you into trouble. > php6 will probably decide to make it not work anymore (for no > technical reason whatsoever), My stance is it "worked" for no technical technical reason whatsoever, but our evaluations are OT for the purposes of this discussion. > so I'm looking to find a nice clean way of keeping my code giving the > same result whilst conform to the probable rules that php6 will > dictate. 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 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 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 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? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
