Going Dynamic with PHP

If you're going to be this generic... by xxxJonBoyxxx · 2006-02-20 06:17 · Score: 2, Insightful

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.)

OOP by onion2k · 2006-02-20 06:29 · Score: 5, Insightful

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.

--
http://twitter.com/onion2k

Re:OOP by IgnoramusMaximus · 2006-02-20 07:34 · Score: 4, Insightful

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.
Re:OOP by ctr2sprt · 2006-02-20 08:01 · Score: 2, Insightful

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 file descriptor is the object. The code at the top of read() is determining the object type (or class). And the helper functions are class methods. 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 encapsulation (of the namespace variety) too.
As noted many times, you can write an OOP in any language. It's just easier to do it in a language that's designed for it. The compiler (or interpreter) does more of the work for you. For instance, you don't need to write the type-checking code, nor do you need to pollute your namespace and worry about collisions. And if you later want to add a new descriptor type, such as for a userland memory-based file, all you need to do is write a new class. All the functions or classes which operate on the other descriptor types will work, unmodified, on the new type. (That's the real code reuse: on the application side, not the library side.)
Re:OOP by IgnoramusMaximus · 2006-02-20 08:23 · Score: 4, Insightful

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 ...

Not The Best Choice For Maintainable Code by tres · 2006-02-20 06:33 · Score: 3, Insightful

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) 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.

--
Notes From Under *nix: blas.phemo.us

Kinda Like Ruby by pkulak · 2006-02-20 06:35 · Score: 3, Insightful

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.

Any fool can code Perl... by iBod · 2006-02-20 06:48 · Score: 4, Insightful

Any fool can code Perl, just like any fool can code PHP/C/Java/VB/Smalltalk/COBOL etc. etc.

Anyone can write code, but very few can write really great code, that reduces the problem to the essential elements and uses the simplest approach to the problem, with the tool (i.e. language) in hand.

You can write shit code in ANY language. You can also write good code in ANY language (within the limitations of the language).

What you're saying is like "Spanish for People who can't speak in German".

It's nonsense and insulting at the same time.

You need to express yourself or solve the problem within the framework of the language you have.

You might choose a different language for a particular task, but if the language is a given, a good poet (or programmer) will make the best of it.

A better language doesn't make one a better programmer (or poet).

Re:Any fool can code Perl... by panaceaa · 2006-02-20 08:33 · Score: 2, Insightful

A better language doesn't make one a better programmer

I agree with this point for good programmers, but for inexperienced programmers a better language can certainly make one a better programmer. The common example is VB, which allows people with basically no programming experience to develop simple applications. But even Java's success in enterprise software is due to the proliferation of design patterns such as EJBs and MVC -- which have basically been ingrained into the language itself. These patterns allow a team of inexperienced programmers to separate complex projects into manageable pieces and use well established integration points.

Without Java's patterns many teams would be unable to come up with coherent systems in a timely manner. Projects would instead stumble while developers try to invent new architectures and learn from their mistakes. In addition, the adoption of these shared principals makes it much easier for new developers to jump into a project since the underlying design is likely similar to previous projects -- even if the code itself is absolute crap. Therefore the programmer who coded the absolute crap IS a better programmer since his code is still maintainable due to the choice of language.

--
my blog

OO PHP 5 == Java Lite (and slightly broken) ?? by Anonymous Coward · 2006-02-20 06:51 · Score: 0, Insightful

Comments that a friend made: PHP 5 -- when using the OO -- looks a lot like Java, except no real threads, no security (sandbox), no WeakReferences and other GC niceties. Enjoy!

Re:Experiences by Tenareth · 2006-02-20 07:48 · Score: 3, Insightful

Yeah, the inability to scale is the primary reason all the porn sites use it...

And why we have a lot of high traffic sites that have no issue with it...

Threading != Scalability. Threading is only needed if you do certain types of tasks that need it.

In programming, there is no silver bullet, there are lots of tools suited for different jobs, PHP fits in a lot of those places, Java in others, other languages elsewhere. Threading isn't a "Oh, I'll multithread it, that'll make it faster" type of magic button.

--
This sig is the express property of someone.

Re:PHP 4 V. 5 by Parham · 2006-02-20 08:05 · Score: 2, Insightful

Your comment is true, but the same can be said about Perl (it just sounded like you were putting down PHP only).

Re:PHP 4 V. 5 by jZnat · 2006-02-20 08:22 · Score: 2, Insightful

This is what frameworks are for. Security and performance conscious people like myself write them so that other neophytes and developers alike can make good PHP apps without worrying about those things.

--
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'

Re:PHP 4 V. 5 by masklinn · 2006-02-20 09:40 · Score: 4, Insightful

Not enforcing Object Oriented programming is actually a very good thing, one of the few good things in PHP5.

Giving the option to use OOP (with a good object system, which PHP doesn't have) is good, forcing it on the poor user and preventing him to write as much as a line of code outside of a damn class is stupid, and is a god damn failure of both Java and C#.

While OOP is a good idea for some problem, others are better solved using more imperative or functional styles. That's why I much prefer Ruby or Python to Java: while they have great object models, they don't try to beat you with an ugly stick if you don't wrap every damn thing in a useless class that is only here because the language absolutely forbids you from doing otherwise.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler

Re:Experiences by masklinn · 2006-02-20 09:49 · Score: 2, Insightful

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..

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler

Ruby? by Some+Random+Username · 2006-02-20 09:50 · Score: 2, Insightful

You mean kinda like every language that supports OO design? None of this is even remotely ruby specific, or even ruby inspired.

Re:[OFF] Re:PHP's Comeupance by caffeination · 2006-02-20 11:58 · Score: 2, Insightful

You're really overreacting mate, especially since the kind of english being put down is the sort that's poor and lazy when the speaker could just as easily speak normal english. At least you included the word somehow as a handy comfort zone.
Now, how to take away the flamey tone of this reply? Common ground!

17 of 222 comments (clear)