# jochem@xxxxxxxxxxxxx / 2007-04-18 11:54:59 +0200:
> Roman Neuhauser wrote:
> > That's an incident waiting to happen, and forbidding static calls of
> > instance methods is an (intended) anti-footshooting measure.
>
> nothing an isset($this) didn't/doesn't solve - they gave me the php gun, so
> let me decide whether or not to and potential foot/head shots in my code ...
> thats my opinion anyway .. not that it counts for much.
well, they gave me the php gun too, and I'd like it fixed so that it's a
bit safer for me. it's not just my code I have to read, and if the
language could have a feature that would allow me to decide whether
$this is a concern just from looking at the method signature, I'm all
for it.
> 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.
> 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.
> now I understand that you might be inclined to say the design is bad - which
> is fair enough - but please realise my question is not whether is should be done
> but how.
By splitting the two things.
> maybe an example would help (severely cutdown code):
>
> class DB {
Cut a bit more ... ;)
> }
>
> the above class can be used in 2 ways:
>
> 1. statically - allowing simple queries in the default implicit transaction of the
> 'current' connection:
>
> DB::query("SELECT * FROM foo WHERE id=?", $id);
>
> 2. a method call of a DB object (which means one uses an automatically created
> explicit transaction for all calls via that instance of DB, within the context
> of the 'current' connection)
>
> $db = new DB(); // start an explicit transaction
> try {
> $db->query("SELECT * FROM foo WHERE id=?", $id);
> $db->query("UPDATE foo SET bar=? WHERE id=?", 'cheese', $id);
> $db->commit();
> } catch (DBException $e) {
> $db->rollback();
> }
I wouldn't do it that way. A single class should not be a database
driver *and* manage connections.
> consider that this question arises because I have a DB class that works this
> way and when it was written (in conjunction with a nice guy named Ard Biesheuvel,
> a very clever chap, who has done some work on the actual php engine and the firebird extension)
> the code was legal and works like a charm (and 10000's of lines of code are in use/production).
So much hardwiring... Yeah, code tends to bloat like hell when you don't
separate things a bit.
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.
--
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
