On Mon, April 16, 2007 9:33 am, Roman Neuhauser wrote: > # otto.wyss@xxxxxxxxxx / 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
