Re: [PHP] Json.php
On Fri, April 20, 2007 3:19 am, Jochem Maas wrote: > Richard Lynch wrote: >> On Thu, April 19, 2007 2:25 am, Roman Neuhauser wrote: >>> I'm at a complete loss then. Richard, what would you advise to >>> someone >>> in such a messy situation? >> >> I don't really see why anybody is getting bent out of shape about >> 'almostatic' methods in PHP, but if they're maybe gonna go away, >> roll >> out the patch now... > > que? If the OP knows that his code is maybe gonna break, depending on which way the wind blows, he should just roll out the patch NOW rather than waiting around for PHP 6 to be released and break all his code... It really doesn't sound like a huge hairy change to me for the DB class to be re-written as completely static or completely not static, frankly. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
# [EMAIL PROTECTED] / 2007-04-20 10:19:04 +0200: > Richard Lynch wrote: > > On Thu, April 19, 2007 2:25 am, Roman Neuhauser wrote: > >> I'm at a complete loss then. Richard, what would you advise to someone > >> in such a messy situation? > > > > I don't really see why anybody is getting bent out of shape about > > 'almostatic' methods in PHP, but if they're maybe gonna go away, roll > > out the patch now... > > que? too much hanging out with musicians... ;) -- 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
Re: [PHP] Json.php
Richard Lynch wrote: > On Thu, April 19, 2007 2:25 am, Roman Neuhauser wrote: >> I'm at a complete loss then. Richard, what would you advise to someone >> in such a messy situation? > > I don't really see why anybody is getting bent out of shape about > 'almostatic' methods in PHP, but if they're maybe gonna go away, roll > out the patch now... que? > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Thu, April 19, 2007 2:25 am, Roman Neuhauser wrote: > I'm at a complete loss then. Richard, what would you advise to someone > in such a messy situation? I don't really see why anybody is getting bent out of shape about 'almostatic' methods in PHP, but if they're maybe gonna go away, roll out the patch now... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
# [EMAIL PROTECTED] / 2007-04-19 10:50:19 +0200:
> Roman Neuhauser wrote:
> >>> 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 */ }
> }
Existence of $this is YOUR problem only as long as you don't share the
code with anybody else. At that moment, you have made life harder for
someone else.
> 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.
No, I've had virtually zero exposure to Interbase/Firebird, and have had
no idea about the phenomenon you mention. I think it's a problem
because of the ways it reduces quality of the code.
Or does DB not handle database connections? If not, how come the static
call DB::query("SELECT fubar FROM snafu") works? Guess it does things
besides querying (probably why it's a generic "DB" in the first place).
> 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
Split the two functions, and don't try to hide the fact that they're two
functions; after all, if you do it correctly, the static one will
probably end in a different class.
> > write below, is actually only a fraction of those "1's of lines of
> > code".
> >
> >>> Do those 1'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 :-)
Don't try to cram connection management into a db client driver class.
The rest will just fall out of it.
--
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
Re: [PHP] Json.php
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 "1's of lines of code".
>
>>> Do those 1'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
Re: [PHP] Json.php
# [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 "1's of lines of code". > > Do those 1'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
Re: [PHP] Json.php
On Wed, April 18, 2007 4:27 am, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-04-18 04:59:48 -0400:
>> >So only one of these is "kosher"
>> >static:
>> >return Services_JSON::decode($data);
>> >
>> >class:
>> >$json = new Services_JSON;
>> >return $json->decode($data);
>> >but not both.
>>
>> I'm not trying to start (or further add fuel to) any kind of war but
>> instead an earnest question: why not both?
>
> If you don't declare the method static, you might be using $this
> inside,
> possibly indirectly.
>
> class c
> {
> function f()
> {
> if (its_second_friday_this_year()) {
> return get_class($this);
> }
> return 'mostly harmless';
> }
> function g()
> {
> return self::f();
> }
> }
>
> c::g();
>
> That's an incident waiting to happen, and forbidding static calls of
> instance methods is an (intended) anti-footshooting measure.
So...
The problem is, what?
That there's no "self" in g to call 'f' on?
There's no $this instance to get the class name inside of 'f'?
Some languages handle this by creating a canonical sort-of-Singleton
instance to 'be' the one 'self' when this sort of stuff happens.
I think Lisp does that.
Or maybe it was Logo that did it.
Scheme?
Whatever.
I suppose others just say "don't do that", probably C++ and, I
suspect, Java.
Guess that explains the two camps right there, eh?
[shrug]
Personally, I find that PHP non-OOP is a lot more pragmatic-minded
than PHP OOP seems to be going these days, and it feels to me kind of
multiple-personality when the PHP OOP stuff is so rigid...
But I cut my teeth on Lisp where data and program were often
interchangable, with self-modifying code, so there ya go.
[shrug]
I'll probably use the PHP OOP stuff so seldom that I don't really care
very strongly, but I would personally lean towards the more pragmatic
let the developer decide what to do that's convenient than locking
down things with error messages about stuff that bothers only the
purists.
Oh well.
If this thread goes on much longer, we should probably take it to
Internals or even off-list...
But I ain't got much more to say than what's here.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Wed, April 18, 2007 3:59 am, Chris Boget wrote: >> So only one of these is "kosher" >> static: >> return Services_JSON::decode($data); >> >> class: >> $json = new Services_JSON; >> return $json->decode($data); >> but not both. > > I'm not trying to start (or further add fuel to) any kind of war but > instead > an earnest question: why not both? There's some sort of OOP "principle" that a static function shouldn't be allowed to be called on an instance, or you shouldn't be allowed to instantiate a static class or somesuch thing... I don't really remember what the driving force behind it is, but it's in the Internals archives with links to Wikipedia OOP articles if you want to find it. It doesn't seem very PHPragmatic to me, but apparently it's Very Important to some OOP advocates. I think the principles are named after some dude whose name is Polish or at least Eastern European, and it starts with a 'W' if that helps find the thread/link... I want to say Wronski, but that's Quidditch, not OOP. :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 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 1'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
t
Re: [PHP] Json.php
# [EMAIL PROTECTED] / 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 1'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 1'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
Re: [PHP] Json.php
On 4/17/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Mon, April 16, 2007 10:20 am, Tijnema ! wrote:
> And btw, I think it's better not to create a new link to the class
> each time the function is called, but just use ::
> if (!function_exists('json_encode')) {
>function json_encode($data) {
>return Services_JSON::encode($data);
>}
> }
>
> and probably also one for decoding.
>
> if (!function_exists('json_decode')) {
>function json_decode($data) {
>return Services_JSON::decode($data);
>}
> }
Actually, if I understand the flame wars of Internals correctly,
whichever one of those is correct, the other one ain't gonna work in
PHP 6...
Or so I gather from the OOP purists fighting the OOP zealots on
PHP-Internals.
I may be 100% wrong, of course, regarding not only the outcome of this
flame-fest, but even if it applies to this JSON thingie.
I see that using the class static wouldn't work, because of the $this
thing... I just tried, and working with Services_JSON::encode()
doesn't work, while $json = new Services_JSON(); $json->encode() does
work :)
It's my fault, i thought there was only 2 functions inside the class,
encode & decode. and that those functions were not using any other
functions inside the class.
Tijnema
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-04-18 04:59:48 -0400:
>>> So only one of these is "kosher"
>>> static:
>>> return Services_JSON::decode($data);
>>>
>>> class:
>>> $json = new Services_JSON;
>>> return $json->decode($data);
>>> but not both.
>> I'm not trying to start (or further add fuel to) any kind of war but
>> instead an earnest question: why not both?
>
> If you don't declare the method static, you might be using $this inside,
> possibly indirectly.
>
> class c
> {
> function f()
> {
> if (its_second_friday_this_year()) {
> return get_class($this);
> }
> return 'mostly harmless';
> }
> function g()
> {
> return self::f();
> }
> }
>
> c::g();
>
> 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.
but a practical question for you Roman (seeing as your very much into OOP),
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?
maybe an example would help (severely cutdown code):
class DB {
public function conn()
{
$confClass = self::getConfClass();
return self::_conn($confClass);
}
private function _conn($confClass)
{
static $dbConn = array();
if (isset($this) && isset($this->transid))
return $this->transid;
if (!isset($dbConn[$confClass])) {
// set up a new connection and
// store id in $dbConn[$confClass]
}
return $dbConn[$confClass];
}
function query($sql) {
// get ibase connection OR transaction id
// depending on whether we are an object with a transid or not
$connId = self::conn();
$args = func_get_args();
$args = self::resolveArgs($args);
array_unshift($args, $connId);
// the return val from ibase_query is actually
// wrapped in a ResultSet object in the real code
return call_user_func_array('ibase_query', array_values($args));
}
}
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();
}
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. 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 1's of lines of code are in
use/production).
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
# [EMAIL PROTECTED] / 2007-04-18 04:59:48 -0400:
> >So only one of these is "kosher"
> >static:
> >return Services_JSON::decode($data);
> >
> >class:
> >$json = new Services_JSON;
> >return $json->decode($data);
> >but not both.
>
> I'm not trying to start (or further add fuel to) any kind of war but
> instead an earnest question: why not both?
If you don't declare the method static, you might be using $this inside,
possibly indirectly.
class c
{
function f()
{
if (its_second_friday_this_year()) {
return get_class($this);
}
return 'mostly harmless';
}
function g()
{
return self::f();
}
}
c::g();
That's an incident waiting to happen, and forbidding static calls of
instance methods is an (intended) anti-footshooting measure.
--
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
Re: [PHP] Json.php
So only one of these is "kosher" static: return Services_JSON::decode($data); class: $json = new Services_JSON; return $json->decode($data); but not both. I'm not trying to start (or further add fuel to) any kind of war but instead an earnest question: why not both? thnx, Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Richard Lynch wrote: > On Tue, April 17, 2007 4:40 pm, Jochem Maas wrote: >> Richard Lynch wrote: > > So only one of these is "kosher" > static: > return Services_JSON::decode($data); > > class: > $json = new Services_JSON; > return $json->decode($data); > > but not both. ah yes that holy war, it's a wait and see situation. I'm rooting for the pragmatists ... so if they want to borrow my broadsword they only need ask ;-) > > >>> Or so I gather from the OOP purists fighting the OOP zealots on >>> PHP-Internals. >> isn't a purist and a zealot the same in this context? aren't they both >> trying to slay the OOP pragmatists? >> >> (makes you want to say 'oops' don't you think ;-) > > I meant what I said and I said what I meant. > > It's up to you to figure it out. :-) in your own immortal words: *sheesh* :-D > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Tue, April 17, 2007 4:40 pm, Jochem Maas wrote:
> Richard Lynch wrote:
>> On Mon, April 16, 2007 10:20 am, Tijnema ! wrote:
>>> And btw, I think it's better not to create a new link to the class
>>> each time the function is called, but just use ::
>>> if (!function_exists('json_encode')) {
>>>function json_encode($data) {
>>>return Services_JSON::encode($data);
>>>}
>>> }
>>>
>>> and probably also one for decoding.
>>>
>>> if (!function_exists('json_decode')) {
>>>function json_decode($data) {
>>>return Services_JSON::decode($data);
>>>}
>>> }
>>
>> Actually, if I understand the flame wars of Internals correctly,
>> whichever one of those is correct, the other one ain't gonna work in
>> PHP 6...
>
> which flamewar ... I've completely missed it ... or was a while back?
> and what exactly is 'those' referring to in that last comment?
It's awhile back, and it's about whether you can call a static
function as if it were a method or not.
So only one of these is "kosher"
static:
return Services_JSON::decode($data);
class:
$json = new Services_JSON;
return $json->decode($data);
but not both.
>> Or so I gather from the OOP purists fighting the OOP zealots on
>> PHP-Internals.
>
> isn't a purist and a zealot the same in this context? aren't they both
> trying to slay the OOP pragmatists?
>
> (makes you want to say 'oops' don't you think ;-)
I meant what I said and I said what I meant.
It's up to you to figure it out. :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Richard Lynch wrote:
> On Mon, April 16, 2007 10:20 am, Tijnema ! wrote:
>> And btw, I think it's better not to create a new link to the class
>> each time the function is called, but just use ::
>> if (!function_exists('json_encode')) {
>>function json_encode($data) {
>>return Services_JSON::encode($data);
>>}
>> }
>>
>> and probably also one for decoding.
>>
>> if (!function_exists('json_decode')) {
>>function json_decode($data) {
>>return Services_JSON::decode($data);
>>}
>> }
>
> Actually, if I understand the flame wars of Internals correctly,
> whichever one of those is correct, the other one ain't gonna work in
> PHP 6...
which flamewar ... I've completely missed it ... or was a while back?
and what exactly is 'those' referring to in that last comment?
>
> Or so I gather from the OOP purists fighting the OOP zealots on
> PHP-Internals.
isn't a purist and a zealot the same in this context? aren't they both
trying to slay the OOP pragmatists?
(makes you want to say 'oops' don't you think ;-)
>
> I may be 100% wrong, of course, regarding not only the outcome of this
> flame-fest, but even if it applies to this JSON thingie.
can't say because I haven't the foggiest as to what may be applied :-)
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Mon, April 16, 2007 10:20 am, Tijnema ! wrote:
> And btw, I think it's better not to create a new link to the class
> each time the function is called, but just use ::
> if (!function_exists('json_encode')) {
>function json_encode($data) {
>return Services_JSON::encode($data);
>}
> }
>
> and probably also one for decoding.
>
> if (!function_exists('json_decode')) {
>function json_decode($data) {
>return Services_JSON::decode($data);
>}
> }
Actually, if I understand the flame wars of Internals correctly,
whichever one of those is correct, the other one ain't gonna work in
PHP 6...
Or so I gather from the OOP purists fighting the OOP zealots on
PHP-Internals.
I may be 100% wrong, of course, regarding not only the outcome of this
flame-fest, but even if it applies to this JSON thingie.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Mon, April 16, 2007 9:33 am, Roman Neuhauser wrote: > # [EMAIL PROTECTED] / 2007-04-16 14:03:55 +0200: >> Jochem Maas wrote: >> > >> >that's going to make it completely impossible to use then isn't it. >> >no way you could possibly wrap the class/objects functionality in a >> wrapper >> >function. >> > >> At the moment it's sufficient, since I've now time to figure out how >> the >> Json package can be installed. Then I can switch to use the usual >> json_encode function. Thanks. > > What I don't understand is why you're going from a general interface > > $someObject->decode($string); # if it quacks like a JSON decoder... > > to a narrow one: > > json_decode($string); # you either have the function or you're > screwed. > > Tight coupling -> inflexible code. This seems pretty ridiculous argument to me. You either have JSON isntalled, or you don't. If you have it, having it as an OOP thingie or as a function doesn't make any real difference if you know how to write decent code in the first place. It's not like it's any easier to swap out the current JSON package for a mythical new one. Global search and replace or writing a wrapper function or whatever is going to be equally easy. Any real pain will be in whether the substitute JSON actually outputs the same thing as the one you used before, not in the syntatic sugar/bloat of having: $json = new json(); $foo_json = $json->encode($foo); versus $foo_json = json_encode($foo); Getting all bent out of shape about OOP versus procedural just makes no sense to me, if one has competent programmers... If one doesn't have competent programmers, then does it really matter which one you use, in the long run? -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Sat, April 14, 2007 3:11 am, Otto Wyss wrote: > I've seen a json.php file somewhere in a project for cases where the > json module isn't installed (e.g. PHP4), yet I can't find that project > again. Is there an official or unofficial download site for json.php? > > Why isn't this available in the PHP manual > (http://ch2.php.net/manual/de/ref.json.php)? I think JSON is new enough to have only ever lived in PECL. http://pecl.php.net -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On 4/16/07, Jochem Maas <[EMAIL PROTECTED]> wrote:
Otto Wyss wrote:
> Tijnema ! wrote:
>>
>> *ROFLMFAO*...Did you actually try google for json.php?
>> Second result:
>> http://mike.teczno.com/JSON/JSON.phps
>>
> This doesn't have a json_encode but needs a $json object which then
> could be used as $json->encode(...). Thanks anyway.
that's going to make it completely impossible to use then isn't it.
no way you could possibly wrap the class/objects functionality in a wrapper
function.
if (!function_exists('json_encode')) {
function json_encode($data) {
$json = new JSON; // or whatever the class is called.
return $json->encode($data);
}
}
The class is called Services_JSON, not JSON.
And btw, I think it's better not to create a new link to the class
each time the function is called, but just use ::
if (!function_exists('json_encode')) {
function json_encode($data) {
return Services_JSON::encode($data);
}
}
and probably also one for decoding.
if (!function_exists('json_decode')) {
function json_decode($data) {
return Services_JSON::decode($data);
}
}
omg that was hard.
Definitely not :)
Tijnema
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Robert Cummings wrote:
> On Mon, 2007-04-16 at 10:49 -0400, tedd wrote:
>> At 8:41 AM -0500 4/16/07, Philip Thompson wrote:
>>> On Apr 16, 2007, at 4:40 AM, Jochem Maas wrote:
>>>
Otto Wyss wrote:
> Tijnema ! wrote:
>> *ROFLMFAO*...Did you actually try google for json.php?
>> Second result:
>> http://mike.teczno.com/JSON/JSON.phps
>>
> This doesn't have a json_encode but needs a $json object which then
> could be used as $json->encode(...). Thanks anyway.
that's going to make it completely impossible to use then isn't it.
no way you could possibly wrap the class/objects functionality in a wrapper
function.
if (!function_exists('json_encode')) {
function json_encode($data) {
$json = new JSON; // or whatever the class is called.
return $json->encode($data);
}
}
omg that was hard.
>>> Can't you just feel the love in the room? That's the kind of support
>>> I like to see! =P
>>>
>>> ~PT
>>
>> Yep, it must be spring.
>
> It's the difference between free support and paid support. In paid
> support the love is all fake... in free support, what you feel is the
> real deal :)
yeah! tough love.
if the man complains the fishing lesson is not a fish he's liable to
be gently beaten with the fishing rod.
>
> Cheers,
> Rob.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On Mon, 2007-04-16 at 10:49 -0400, tedd wrote:
> At 8:41 AM -0500 4/16/07, Philip Thompson wrote:
> >On Apr 16, 2007, at 4:40 AM, Jochem Maas wrote:
> >
> >>Otto Wyss wrote:
> >>>Tijnema ! wrote:
>
> *ROFLMFAO*...Did you actually try google for json.php?
> Second result:
> http://mike.teczno.com/JSON/JSON.phps
>
> >>>This doesn't have a json_encode but needs a $json object which then
> >>>could be used as $json->encode(...). Thanks anyway.
> >>
> >>that's going to make it completely impossible to use then isn't it.
> >>no way you could possibly wrap the class/objects functionality in a wrapper
> >>function.
> >>
> >>if (!function_exists('json_encode')) {
> >>function json_encode($data) {
> >>$json = new JSON; // or whatever the class is called.
> >>return $json->encode($data);
> >>}
> >>}
> >>
> >>omg that was hard.
> >
> >Can't you just feel the love in the room? That's the kind of support
> >I like to see! =P
> >
> >~PT
>
>
> Yep, it must be spring.
It's the difference between free support and paid support. In paid
support the love is all fake... in free support, what you feel is the
real deal :)
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
At 8:41 AM -0500 4/16/07, Philip Thompson wrote:
On Apr 16, 2007, at 4:40 AM, Jochem Maas wrote:
Otto Wyss wrote:
Tijnema ! wrote:
*ROFLMFAO*...Did you actually try google for json.php?
Second result:
http://mike.teczno.com/JSON/JSON.phps
This doesn't have a json_encode but needs a $json object which then
could be used as $json->encode(...). Thanks anyway.
that's going to make it completely impossible to use then isn't it.
no way you could possibly wrap the class/objects functionality in a wrapper
function.
if (!function_exists('json_encode')) {
function json_encode($data) {
$json = new JSON; // or whatever the class is called.
return $json->encode($data);
}
}
omg that was hard.
Can't you just feel the love in the room? That's the kind of support
I like to see! =P
~PT
Yep, it must be spring.
tedd
--
---
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
# [EMAIL PROTECTED] / 2007-04-16 14:03:55 +0200: > Jochem Maas wrote: > > > >that's going to make it completely impossible to use then isn't it. > >no way you could possibly wrap the class/objects functionality in a wrapper > >function. > > > At the moment it's sufficient, since I've now time to figure out how the > Json package can be installed. Then I can switch to use the usual > json_encode function. Thanks. What I don't understand is why you're going from a general interface $someObject->decode($string); # if it quacks like a JSON decoder... to a narrow one: json_decode($string); # you either have the function or you're screwed. Tight coupling -> inflexible code. -- 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
Re: [PHP] Json.php
On Apr 16, 2007, at 4:40 AM, Jochem Maas wrote:
Otto Wyss wrote:
Tijnema ! wrote:
*ROFLMFAO*...Did you actually try google for json.php?
Second result:
http://mike.teczno.com/JSON/JSON.phps
This doesn't have a json_encode but needs a $json object which then
could be used as $json->encode(...). Thanks anyway.
that's going to make it completely impossible to use then isn't it.
no way you could possibly wrap the class/objects functionality in a
wrapper
function.
if (!function_exists('json_encode')) {
function json_encode($data) {
$json = new JSON; // or whatever the class is called.
return $json->encode($data);
}
}
omg that was hard.
Can't you just feel the love in the room? That's the kind of support
I like to see! =P
~PT
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Jochem Maas wrote: that's going to make it completely impossible to use then isn't it. no way you could possibly wrap the class/objects functionality in a wrapper function. At the moment it's sufficient, since I've now time to figure out how the Json package can be installed. Then I can switch to use the usual json_encode function. Thanks. O. Wyss -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Otto Wyss wrote:
> Tijnema ! wrote:
>>
>> *ROFLMFAO*...Did you actually try google for json.php?
>> Second result:
>> http://mike.teczno.com/JSON/JSON.phps
>>
> This doesn't have a json_encode but needs a $json object which then
> could be used as $json->encode(...). Thanks anyway.
that's going to make it completely impossible to use then isn't it.
no way you could possibly wrap the class/objects functionality in a wrapper
function.
if (!function_exists('json_encode')) {
function json_encode($data) {
$json = new JSON; // or whatever the class is called.
return $json->encode($data);
}
}
omg that was hard.
>
> O. Wyss
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Satyam wrote: www.json.org lists all json resources in any language you care to think of. I must admit I haven't checked each reference but the ones I have have only packages to install and not a PHP source. Maybe I wasn't clear when asking. O. Wyss -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
Tijnema ! wrote: *ROFLMFAO*...Did you actually try google for json.php? Second result: http://mike.teczno.com/JSON/JSON.phps This doesn't have a json_encode but needs a $json object which then could be used as $json->encode(...). Thanks anyway. O. Wyss -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
www.json.org lists all json resources in any language you care to think of. Satyam - Original Message - From: "Otto Wyss" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, April 14, 2007 10:11 AM Subject: [PHP] Json.php I've seen a json.php file somewhere in a project for cases where the json module isn't installed (e.g. PHP4), yet I can't find that project again. Is there an official or unofficial download site for json.php? Why isn't this available in the PHP manual (http://ch2.php.net/manual/de/ref.json.php)? O. Wyss -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 269.4.0/760 - Release Date: 13/04/2007 20:04 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Json.php
On 4/14/07, Otto Wyss <[EMAIL PROTECTED]> wrote: I've seen a json.php file somewhere in a project for cases where the json module isn't installed (e.g. PHP4), yet I can't find that project again. Is there an official or unofficial download site for json.php? Why isn't this available in the PHP manual (http://ch2.php.net/manual/de/ref.json.php)? O. Wyss *ROFLMFAO*...Did you actually try google for json.php? Second result: http://mike.teczno.com/JSON/JSON.phps Tijnema -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Json.php
I've seen a json.php file somewhere in a project for cases where the json module isn't installed (e.g. PHP4), yet I can't find that project again. Is there an official or unofficial download site for json.php? Why isn't this available in the PHP manual (http://ch2.php.net/manual/de/ref.json.php)? O. Wyss -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
