Roman Neuhauser wrote:
> # 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.
sure, I wasn't trying to offend! - in practice much of what you have shown here
(alot of interesting stuff) has been OOP code.
>
>> 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. php6 will probably decide to
make it not work anymore (for no technical reason whatsoever), 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.
>
>> 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.
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.
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).
>
>> 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.
so much hardwiring? excuse me for not being a metahacking god ... but really I have just a
single interface (DB::query()) that is being used in certain places within a core framework
that is the basis for a number of projects and the number of calls to DB::query() (or $db->query())
is fairly limited ... but that doesn't mean I look forward to re-engineering the code
inside DB::query() so that it conforms to the probable php6 requirement of not being
allowed to call a 'non-static' method statically whilst keeping the resulting functionality
indentical to what I have now ... especially given that it works fine now and I see no reason to
be forced to re-engineer just because somebody doesn't trust me with a php gun.
I only have to rewrite the code in the relevant DB class methods. but it will be a PITA.
I'm guessing that DB::query() will have to become a transparent wrapper to encapsulated
transaction/query objects.
and if it becomes illegal to do this:
DB {
static function query() { echo "SQL!"; }
}
$db = new DB;
$db->query();
then I have no idea right now how I'll go about making it work. but I'm going on the assumption
that calling the static methods via an instance of a class will not be a problem - please nobody
tell me I'm wrong here!
anyway, thanks for the feedback.
>
> 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 have me, and I'll find a way through without having to change 1000's LOC.
the 10000's LOC concern me in so far that if/when my current class breaks (because the engine
starts to disallow my code) I will have to fix it simply because the class's functionality
is the basis for an ORM wotsit that is used by some of my biggest projects.
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
