Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Going Dynamic with PHP 222

Posted by ScuttleMonkey from the not-the-bastard-child-of-languages-anymore dept.
Five-Oh writes to tell us that IBM DeveloperWorks has an interesting article about the OO advantages of PHP V's new features. From the article: "PHP V5's new object-oriented programming features have raised the level of functionality in this popular language significantly. Learn how to use the dynamic features of PHP V5 to create objects that bend to fit your needs."
This discussion has been archived. No new comments can be posted.

Going Dynamic with PHP More

Going Dynamic with PHP

Comments Filter:

  • PHP's Comeupance (Score:5, Informative)

    by (1+-sqrt(5))*(2**-1) ( 868173 ) <1.61803phi@gmail.com> on Monday February 20, 2006 @02:08PM (#14762257) Homepage
    I rediscovered PHP last week after a year-long hiatus, and was surpised to find that it approacheth Java in reflection and information hiding; that said, there are some lamentable lacunæ:
    • Class constants must be string literals and only string literals (no variables, arrays or objects).
    • Type-hinting is confined to arrays and objects (feature?).
    The unadorned output of phpDocumentor, PHP's analog to JavaDoc, is also suboptimal; for documenting PHP, therefore, go Doxygen [doxygen.org].

    • Re:PHP's Comeupance (Score:5, Funny)

      by Hal_Porter ( 817932 ) on Monday February 20, 2006 @03:45PM (#14762885)
      Dear (1+-sqrt(5))*(2**-1),

      I must say, Sir, that I salute you for your post. Not only is in Informative, it is also well drafted in the Queens English, not in the debased language of Internetland. Furthermore, you have managed to obtain the coveted pole position of posters, so to speak. As I write this epistle of congratulations, I shall drink a toast of finest port wine to you, and I wish that your correspondence with the world shall continue for all eternity.

      If I may be so bold as to trouble you with two requests, it would be these. Firstly, may I post a copy of your memorandum above the post to which I fasten my servants when I whip them for dumb insolence and/or sundry grammatical errors, including the splitting of infinitives or the use of the accursed Internet language? Secondly, my wife is expecting our first child, conceived soon after she spent a night in my servants quarters, teaching them virtue of prayer. Would it be presumptive of me to command her to name her baby (1+-sqrt(5))*(2**-1). We are unsure at present of the sex of the baby, since we have emigrated to the 19th Century to escape the linguistic slovenliness of the later epochs, but we feel that such a name would distinguish a child of either gender?

      Yours, etc
      Hal Porter, esq.
      • Well as long as you bring up grammar:
        1. Sir is not capitalized. This miscreant tendency is American ignorance of the proper title Sir as given during knighthood by royalty. You may call Sir Edmund Hillary with the capitalized Sir. Given your obvious deep familiarity with the 19th century, perhaps I should also refer to Sir Mick Jagger. Some random person on Slashdot most likely has not attained such a title.
        2. "is it informative" - you've got a typo, and informative is not a proper noun, even when cataloguing

    • Re:PHP's Comeupance (Score:4, Informative)

      by sweetnjguy29 ( 880256 ) on Monday February 20, 2006 @05:39PM (#14763465) Journal
      Learned a new word: lacunæ (latin for lake) -- in this context, a gap. Well done, sire!

  • If you're going to be this generic... (Score:3, Insightful)

    by xxxJonBoyxxx ( 565205 ) on Monday February 20, 2006 @02:17PM (#14762329)
    If you're going to be this generic, why lock each class to a single table? (Why not let the name of the table be an argument as well?)

    The answer would seem to be that there is no input validation or output interpretation going on in this sample. So, you can either write a switch block that makes sure your integers are in valid ranges, etc. or go back to individual properties. (Six dozen of one, half of the other.)

    • Amen. My issue with databases and all that is that they are not abstract enough. Either one must create a new table when one wishes to implement a new feature, or one must develop some extremely generic database that is hard to search. I don't think that moving toward Java is necessarily the answer.

      This will be off-topic

      (Six dozen of one, half of the other.)

      Hahaha. That was priceless. I assume you meant, "six of one, half-dozen of the other"? It is fairly humorous, however, to say, "72 of one thing, .5

      • Re:If you're going to be this generic... (Score:5, Funny)

        by sammy baby ( 14909 ) on Monday February 20, 2006 @03:14PM (#14762697) Journal
        My issue with databases and all that is that they are not abstract enough. Either one must create a new table when one wishes to implement a new feature, or one must develop some extremely generic database that is hard to search.

        Well, you could always create a single-table database. Call the single table "Stuff," put a generic autoincrementing key on it, and give it two more columns: a type identifier and a serialized object that contains all the data.

        Of course, you could also stab yourself in the eye. Might be preferable.
    • Actually you could make this class totally generic by having it query the DB for all the field information. That could even include validation to make sure the input is the right type, length, etc. All the info you need for that is in the DB. The problem is that, unless you're just writing a generic DB table editor app, you generally need unique methods for each table/object.

      If you find this kind of thing interesting, it's probably worth checking out some persistance layers like hibernate [hibernate.org] or (for PHP) Pr [phpdb.org]

  • Experiences (Score:5, Interesting)

    by truthsearch ( 249536 ) on Monday February 20, 2006 @02:19PM (#14762343) Homepage Journal
    It's a huge step forward for OO development in PHP.

    BUT it's still got all the crud of PHP4. For those transitioning from PHP4 objects one great feature is the new warning when using the older style of classes. However all of those things people find quirky about PHP4 still exist. For example, now you can force a function parameter to be a certain type of object, but not a basic type. You still can't even fully overload a function.

    My view is that it's two steps forward and one step back. They need to consider deprecating features and making a php.ini option to not allow the use of any deprecated features.
    • You still can't even fully overload a function.

      How so? I'm not saying that PHP classes are fully OO, but overloading, AFAIK, is completely supported.

      They need to consider deprecating features and making a php.ini option to not allow the use of any deprecated features.

      If backward compatibility could be turned on and off, I'd prefer some sort of php_compatibility( COMPAT_PHP4 ) type call, coupled with a error_reporting() flag that could be used to flag obsoleted things in order to make it easy to bring

      • Re:Experiences (Score:2, Informative)

        by T-Ranger ( 10520 )
        You have the choice of either type hinting OR function overloading. If you use type hinting, you have to pass that function exactly those types (and not a null, either) . And its not realy function overloading; you, as the developer, need to resolve what your being passed. Most everything else that allows overloading, you write multiple functions, and the compiler decides what to do.

      • Re:Experiences (Score:3, Informative)

        by shmlco ( 594907 )
        "At that point function names could be standardized..."

        YES!!!! Not just names, but parameter order as well. Most the functions work one way, but there are just enough that reverse target parameters that you can never be quite sure you got it right.

        PHP: Over a billion functions served... and counting.

    • Although technically there is nothing python can do that php can't I am afraid PHP usage will continue to decline till they fix their namespace problems and make an effort to standardise their function calls.

      • Re:Experiences (Score:3, Insightful)

        by masklinn ( 823351 )

        technically there is nothing python can do that php can't

        Turing-completeness also states that, technically, there is nothing Python can do that Whitespace can't. That doesn't mean you have to use Whitespace..

    • There's a type hint for arrays. The other types need no explicit type hint as PHP is meant for web development and both HTTP and HTML only support strings. It would be bad to have a function call fail because your string of digits is not casted to an int. Of course you still can, but than there's still no use for a type hint in that case.

      Same goes for overloading. If you need to cast your parameters you could also write method_for_number and use a string of digits or an int or a float.

  • OOP (Score:5, Insightful)

    by onion2k ( 203094 ) on Monday February 20, 2006 @02:29PM (#14762409) Homepage
    I'm a fan of using objects in the right place .. but to suggest they increase the functionality of a language is simply wrong. They allow for better (well, different) organisation of code, easier reuse, and improved encapsulation over procedural or functional coding styles, but they don't actually allow you to do anything that can't be done using any other approach. The functionality of the language remains the same.
    • Very true. And specifically in PHP's case objects provide encapsulation that's otherwise impossible. If they simply provided modular scope (similar to Python) I probably wouldn't use PHP objects half as often.
    • They allow for better (well, different) organisation of code, easier reuse, and improved encapsulation over procedural or functional coding styles,

      As a long-time OOP skeptic and criticit, I have not seen very convincing examples of of these (except maybe for systems software). I don't want to start an OOP war, but am just suggesting that people not use objects just because somebody says to (unless they are your boss and order you).

      "Organization of code" tends to be very subjective. What makes one brain ha

      • Re:OOP (Score:5, Insightful)

        by IgnoramusMaximus ( 692000 ) on Monday February 20, 2006 @03:34PM (#14762828)
        I don't want to start an OOP war, but am just suggesting that people not use objects just because somebody says to (unless they are your boss and order you).

        I am with you on this one, although, unlike you, I used to be swept up at one time in all the early OO hype to a degree (back in the Smalltalk days - which by the way is probably the only coherent OO environment), only to realise, by experience, that it was for the most part just that: unsubstantiated hype. Object Orientation has applications, notably in situations close to its original aims of simulation of physical universe (as in the Simula language which started it all), which in modern software is found in things like PC games. But this paradigm has been overused, abused and stretched beyond its breaking point to try to cover all possible cases, no matter how ill fitting. And in the process it has consistently failed to deliver on most of its promises (other then to pad pockets of various charlatans and OO "framework, IDE, grill and taco stand" makers). My experience has thought me that contrary to what OOP priests wish us to believe, "complexity hiding" (usually by masking it by more OO-gunk complexity) is not the answer to reusability, cooperative maintenance and so on. The answer is: simplicity. That is the most maintainable code is the one which can be fully understood, with ease, by the programmer. OOP does not do that. In fact it introduces a whole new gamut of problems dealing with the hidden workings of pyramidal heaps of classes found in any OOP "framework", each with its own weird quirks and inconsistencies, from which you are supposed to "derrive" your own, as long as you adhere to a million of unwritten and poorly documented rules of use of these, supposedly, "reusable" and "extensible" components. Not to mention that it actively encourages creation of massive, incomprehensible class jungles as one can easily see in places like the JDK.

        Speaking of PHP, its success can be attributed to its simplicity, ease of use and short learning curve. If they keep continuing to "innovate" new piles of ever more trendy crap into the language, it will soon (already is?) lose this advantage. It won't be long before someone comes up with another simple server-side language to replace the morass and the enthusiatic crowds will move onto this new "lighning fast, low footprint" language and begin to "improve it". Rinse, repeat.

        • I can agree with your comments to an extent with respect to OOP being touted as a magic bullet and being pushed for uses in places where it doesn't actually suit. However regarding your comments about the fundamental aspects of OOP such as reusability and encapsulation, I have to respectfully disagree.

          OOP isn't a magic bullet, it won't make any code magically better somehow. If you're a bad programmer who writes crap, then all OOP allows you to do is write more complicated crap. However, OOP can be a fant

          • OOP isn't a magic bullet, it won't make any code magically better somehow. If you're a bad programmer who writes crap, then all OOP allows you to do is write more complicated crap. However, OOP can be a fantastic tool when used properly.

            Unfortunately, this applies to just about any other paradigm. A good assembly coder will write a massive business application in it (it has been done more then once) and he will be able to maintain it quite well too. This does not however mean that assembly lanugage coding

            • I'd agree with that, my only issue with your previous comment was that you seemed to be saying that there were very few good applications for OOP which I disagree with, at least with respect to my own admittedly limited experience. If I misunderstood you then you have my apologies.
              • I'd agree with that, my only issue with your previous comment was that you seemed to be saying that there were very few good applications for OOP which I disagree with, at least with respect to my own admittedly limited experience.

                Your impression comes from this misunderstanding: what I said in effect is that there are indeed very few good uses for OOP when compared to the promises made by its proponents. So, yes I said something of the sort, but it was not an absolute statement by any means. OOP is not qu

      • Re:OOP (Score:3, Insightful)

        by ctr2sprt ( 574731 )
        If you're a programmer, I guarantee that you're using OOP even if you don't use an OOP language.

        Consider the Unix read() function, which can read from any file descriptor: regular file, block or character special, socket, and so on. If you were to write such a function in C, you'd write some code to determine the underlying type of descriptor. Then, based on that type, you'd call a helper function - read_file(), read_special(), read_socket() - to perform the actual read.

        Guess what? That's OOP. The f

        • Re:OOP (Score:5, Insightful)

          by IgnoramusMaximus ( 692000 ) on Monday February 20, 2006 @04:23PM (#14763097)
          Let me take this silly argument to its full comical potential:

          If you're a programmer, I guarantee that you're using SEP (Spiritual Extrusion Programming) even if you don't use a SEP language.

          Consider the Unix read() function, which can read from any file descriptor: regular file, block or character special, socket, and so on. If you were to write such a function in C, you'd write some code to determine the underlying type of descriptor. Then, based on that type, you'd call a helper function - read_file(), read_special(), read_socket() - to perform the actual read. Guess what? That's SEP. The file descriptor is the Spititual Manifestation of a Concept. The code at the top of read() is determining the object type (or Spiritual Element). And the helper functions are Spiritual Invocations. If this is a big project, odds are you'll put all the helper functions for sockets in socket.c, for files in file.c, and so on. And there we have Spiritual Encapsulation (of the namespace variety) too.

          As noted many times, you can write an SEP in any language. It's just easier to do it in a language that's designed for it.

          And so on, etc.

          Newsflash: all of the concepts you describe are 1) long in existence before your favourite paradigm arrived on the scene so that you can try to contort them into it, and 2) can be interpreted ad infinitum with any of the millions of "paradigms" one can concoct on the spot. That is because your paradigm is merely a perspective and not an universal (and only) truth. The whole point of abstract formulations, such as computer software, is that they can conform to nearly infinite number of perspectives and can be projected onto the real, physical universe in an equally large number of ways, which is what makes this whole Information Technology thing so powerful.

          But I fear that long after OOP has been relegated to the dusty bin of history, some ctr2sprt of the future will still argue about how you are really always writing "Quantum Parallax" code, even if you are you are not ...

          • But I fear that long after OOP has been relegated to the dusty bin of history, some ctr2sprt of the future will still argue about how you are really always writing "Quantum Parallax" code, even if you are you are not ...

            Awesome! I remember exactly the same detailed and well-argued articles being posted against the use of procedural code in the 70s. Procedural code was 'just a paradigm', and pointless as it could always be implemented with the right combination of 'GOTO's.

      • Re:OOP (Score:3, Interesting)

        by yintercept ( 517362 )
        OOP is transcendant. OO programmers are on a higher level of existence than procedural programmers. When I OOP, I am charged revolutionary spirit. It feels great! I love thinking in objects and discussing patterns while smoking a pipe in an easy chair.

        Sadly, the main use for PHP is to jam out a script to get a job done. Much as I love objects. I can't help but notice that my primary use of PHP is to grab a string of data from MySQL, pack some HTML around it and present the string to a web server. Writing
    • They allow for better (well, different) organisation of code, easier reuse, and improved encapsulation over procedural or functional coding styles

      And I'm not even sure I'd go that far. Consider, for example, OCaml's module and functor system which allows for a very high degree of code reuse, and a type of encapsulation. It certainly allows for information hiding and a tight type-based relationship between data and functionality.

  • Hosting services stuck on PHP4 (Score:4, Informative)

    by cknudsen ( 891397 ) on Monday February 20, 2006 @02:32PM (#14762424) Homepage
    I'd love to take advantage of some of the PHP5 features. However, most hosting services are still stuck on PHP4. How long has it been now? I am the project manager for WebCalendar, and just like during the transition from PHP3 to PHP4, it's going to be some time before we can drop "legacy" support for PHP4 and take advantage of the cool new features of PHP5. So, for now, WebCalendar and other open source apps will have to stick to PHP4.
    FYI.... PHP developer articles updated daily:
    http://www.devpointer.net/browse.php?l=p&t1=1 [devpointer.net]
    RSS:
    http://www.devpointer.net/browse.php?l=p&t1=1&fmt= rss1 [devpointer.net]
    • Good web-hosts [dreamhost.com] will let you choose between various versions on a per-domain basis. Dreamhost also gives you access to some bits of .htaccess files which I assume you could link *.php4 to the php4 cgi and vice versa for *.php5. Yeah, the cut-rate shared hosters probably don't have the same level of management capabilities, but there are some out there that will let you do some really useful things (ie: ssh access, gcc, svn, cvs, php, ruby, python, mysql, etc, etc, etc). I guess one of their big gaps is wi

  • Not The Best Choice For Maintainable Code (Score:4, Insightful)

    by tres ( 151637 ) on Monday February 20, 2006 @02:33PM (#14762432) Homepage
    From the article:


    Dynamic objects have a lot of power, but they also carry significant risk. First, the complexity of classes increases tremendously when you start writing magic methods. These classes are harder to understand, debug, and maintain. In addition, as integrated development environments (IDEs) become more intelligent, they may experience problems with dynamic classes such as these because when they look up methods on a class, they won't find them.


    This is what I was thinking the entire time I was reading the article. I mean, it's one thing to have to whip up some small project for yourself, it's another to build a project that is maintainable by a group of people.

    I'd bet that Brian W. Kernighan and Rob Pike (The Practice of Programming [bell-labs.com]) would probably recommend against using it. It doesn't provide for clarity, nor does it simplify, it just makes things "easier" for the guy that writes the original code.

    • It doesn't provide for clarity, nor does it simplify, it just makes things "easier" for the guy that writes the original code.

      What? I'd argue that:

      $customer=new Customer();
      $customer->name="Bob";
      $customer->phone="555-1234";
      $customer->insert();

      is much more clear than
      $conn=mysql_connect("localhost","user","password") ;
      mysql_select_db("customers",$conn);
      mysql_query("insert into customers (name,phone) values ('Bob','555-1234')",$conn);
      mysql_close($conn);

      It's cleaner and easier to read.
      • You're right. Your OOP interface is simpler than that second mess of code, which would actually run. Now, add all the stuff you have to write first for the OOP example to work and we'll have a fair comparison.

        Nobody's saying everything has to be done inline, what some folks are saying (and it's reasonable, IMHO), is that there's lots of places where OOP gets in the way more than it helps. Simple functions could abstract your second example out to where it's just as simple as the first example, without havin
      • Please, sir, don't EVER write any ORM.

  • Kinda Like Ruby (Score:3, Insightful)

    by pkulak ( 815640 ) on Monday February 20, 2006 @02:35PM (#14762448)
    So, it's got some of the features of Ruby now, plus a whole lot of crap dragged in from PHP 3 and 4 inluding that crazy mishmash of a function library? Boy, sign me up.

  • I would like to be the first to say... (Score:4, Funny)

    by Yuioup ( 452151 ) on Monday February 20, 2006 @02:36PM (#14762452)
    "welcome to 1967".

    http://en.wikipedia.org/wiki/Simula [wikipedia.org]

    Y
    • "welcome to 1967"
      Seriously though, OOP is *not* a new idea. Alan Kay, inventor of Smalltalk, wrote an article about OOP in the 80s entitled "back to the future", because amongst people who knew about such things, OOP was not a revolutionary idea even then. What's new is its popularity.

  • Crap... (Score:5, Funny)

    by A beautiful mind ( 821714 ) on Monday February 20, 2006 @02:46PM (#14762509)
    I've clicked to another tab to browse at some other site and then I've seen suddently:

    "Slashdot | Going Dynamic with PHP"

    ...as the title of the Slashdot tab. It gave me the creeps until I remembered whats the article about. Phew.

  • Interesting, but ... (Score:3, Interesting)

    by isolationism ( 782170 ) on Monday February 20, 2006 @02:54PM (#14762566) Homepage
    ... There hasn't exactly been widespread adoption of PHP5 at commercial hosting interests, has there. I see PHP's greatest strength being its widespread adoption, not its OO model -- and it doesn't do a lot of good to develop using a technology that is effectively unavailable to host your application unless you want to set up your own co-located server to do it (e.g. even top-notch managed services like Rackspace still come with PHP4).

    Perl is another alternative, and admittedly a pretty popular installation (I imagine anywhere that offers PHP hosting also offers Perl) -- but for someone like me who wants to do the occasional scripting the language is not exactly ideal -- nor is it especially easy to read someone else's code. I think Perl developers are incidentally the most "guilty" party of poorly commented code in FOSS projects, which doesn't help matters.

    As a designer and occasional scripter I was interested in learning more PHP at one time, but now I feel as though it's a bit of a dead end, especially for "bigger" projects. Learning Python seems to be time better spent at this point; I can run a native interpreter as well as Java and .net based interpreters to handle more "enterprise-sized" projects; Python has a stronger OO foundation than PHP in existing versions, is designed to easily integrate with C modules, and reads easily. It's also shown itself to be equal to a broad spectrum of applications from commercial tax forms software (QuickTax) to web application frameworks (Zope) to HTPC frontends (Freevo) to P2P software (BitTorrent).

    As for PHP, roll me over when version 5 is standard across the board and I'll consider taking another look at it.

  • DB_DataObject (Score:2, Informative)

    by schmidt ( 69858 )
    There is an implementation of this idea (and more) in PEAR's DB_DataObject package:

    http://pear.php.net/manual/en/package.database.db- dataobject.php [php.net]
  • I was following PHP5 development until the RC1 deployment, and I was disappointed. There wasn't really much, I yearned for a new, truly OO language. Luckily, about the same time, Ruby on Rails was getting a lot of attention and I checked that out, now I couldn't be happier. I do some contract work in PHP4 and PHP5 sometimes, and I just get this sick feeling. Honestly I'd much rather program in Perl than PHP.
    • There wasn't really much, I yearned for a new, truly OO language

      No why's? Like why were you disappointed with 5rc1? Why did you want a new OO language? Why is a language something that makes you sick or happy? I'm betting you're a fanboi who read something disparaging about 5rc1 from a Ruby programmer. Most importantly, Ruby isn't great because of rails. There is evidence that it isn't being adopted BECAUSE of rails. Anecdotes of non-adoption from PHP/Perl/Java/C++ programmers I have read, typically tried u
  • The one thing I was disappointed about this article is that it doesn't make a "describe $table" call to get the fields for you. You could then extend DBObject to like DBO_customer and the constructor would yank "customer" out of the class name. So then all you really have to do is extend and rename and that's it. No need to directly pass the table name to the constructor.

    Secondly, by modifying the load function to accept an array of id's and implementing the Iterator interface, one can use the object in
    • You can!

      (1) Object factories are a great way to have extremely dynamic objects. Use something like: $customers = DB_Table::new("customers");

      (2) From a MySQL query (and hopefully other DB implementations, too), one can find field information, specifically if a field is the primary key. Thus, if after instantiation of our object, we find a column that is the primary key, allow the object to iterate over it and otherwise iterate in the order specified by a custom ORDER BY statement.

      (3) Why not make each row an

  • While the approach in the article does appear to be quite good for rapid code generation, I personally wouldn't touch it with a ten foot pole if I had a choice, though I was unfortunate enough to have to work with such a setup recently.

    The problem with this kind of setup is that while it works well for simple work, the moment you try and do something more complex, you'll find you have to fight against the API, and the code will end up being a mess in order to do a task that should be quite simple.

    Natura

  • I've almost never seen OO been put to good use with PHP. It's used exclusively as a tool for the developer to write, as the author puts it, "more maintainable code". However, with the (lack of) real complexity and sprawling code bases which accounts for most web sites, it just adds complexity by adding a "system" for the developer.
    Forgetting the developer, it adds nothing, and has a major impact on speed and memory. It adds nothing as in 99,9% of the times I've seen it used, it's 1) stateless and 2) a coll
  • that actually thought it was a well done article?

    Seems a bit better than some of the journalist's moronic rantings that I've seen lately on /.

    Good food for thought, good examples, good examples of the new functions that replace some of the fubar functions in 3 & 4.

  • Awful use of regex (Score:3, Interesting)

    by 1110110001 ( 569602 ) <<ta.tden> <ta> <4090-todhsals>> on Monday February 20, 2006 @08:48PM (#14764537)
    The call method has a preg_match, which is not needed and doesn't match right:
    function __call($method, $args) {
      if(preg_match("/set_(.*)/", $method, $found )) {
        if(array_key_exists($found[1], $this->fields)) {
          $this->fields[$found[1]] = $args[0];
          return true;
        }
      } else if(preg_match("/get_(.*)/", $method, $found)) {
        if(array_key_exists($found[1], $this->fields)) {
          return $this->fields[ $found[1] ];
        }
      }
      return false;
    }
    There is so too much wrong with this simple method:
    • Double quotes altough single qoutes would do it
    • No circumflex at start of regex, thus somerandomshitset_foobar also matches
    • Code is duplicated (array_key_exists)
    • Null would fit much better if someone is trying to use a random name as getter, false could be a valid value for a field
    • $args is used but not checked
    • A string is splitted with an regex?!


    Let's see how it can be done better:
    function __call($method, $args) {
      list($type, $field) = explode('_', $method, 2);
      if(!isset($this->fields[$field])) {
        return null;
      }
      if($type == 'get') {
        return $this->fields[$field];
      }
      if($type == 'set' && isset($args[0])) {
        $this->fields[$field] = $args[0];
        return true;
      }
      return null;
    }
  • My firm is a fairly big fan of WASP (http://wasp.sourceforge.net/ [sourceforge.net]). Check it out.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close