Posted: Sat Nov 13, 2004 10:35 pm
Yeah just my local copy. I find the older versions are quite a bit faster on my creaky old Duron 700.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
It's good that you agree with it as there is no denying that it's flexibility and ones ability to easily grasp it has everything to do with it's success. There is an interesting phenomena in that many of these simple and flexible things have risen to the fore in recent history. Windows and MySQL are two good examples. PHP is more of the same.McGruff wrote: I strongly agree that php's flexibility is a huge strength - ...
There are legions of people that say just this. However, are we trying to step through and close the door behind us? Let 'em in! Just like kids, noob3's are going to make a mess here and there. It's all part of learning.I might never have begun learning to code if it wasn't so easy to get started.
These are design issues. Not paradigm problems. If one grasped these issues merely by understanding OOP, things like the GOF design patterns book would have no need to exist. If you take a look at that grey-around-the-edges thing called the past, you can see that this was being dealt with long before OOP came to the popular fore. The idea of modules is a prime example as such. Even the record or struct can be seen as part of the march towards OOP.But the flip side of this is that a huge amount of php code is badly written, including many popular php apps. Not badly written in the sense that they don't work, but badly written in that there is a very poor separation of concerns thus making them difficult to edit and maintain. I think it is important to try to point people towards the best modern programming practices like OOP, unit testing, XP and so on. That's not an official policy but it is where I concentrate my own efforts on these forums.
RDD (Responsibility Driven Design) is another important stepping stone in the march towards good design. Your term, "poor seperation of concerns" is basically a failure to identify and associate responsibilies or behaviours to given blocks of code. Here is Timothy Budd's explanation of 'Characterization by Behaviour'.Many problems in forum posts fundamentally arise from a poor separation of concerns:...
That said, people (procedural and OOP alike) fail to do this all the time. The nice thing about OOP is that it encourages you to think in more of an OOD fashion. But even still, RDD and OOD can be applied to any language or paradigm. I can call any data structure I want an object if it helps clarify and facilitate the design and understanding of a larger system. To get caught up in the question of whether or not it's a real object is to allow one self to be mired in legality or the 'letter' as opposed to the spirit. And if that's the case, where has the flexibility gone?Timothy Budd wrote: * First capture behaviour of application
* Refine this into behaviour of subsystems
* Refine behaviour descriptions into code
I like to think of myself as a professional, but for many of the things I've done, OOP is complete and utter overkill. To imply that OOP makes sense in all or the majority of situations is to promote a Golden Hammer way of thinking (http://c2.com/cgi/wiki?GoldenHammer). Most craftsmen have multiple tools and never leave all but one in the truck!Some of our members will be thinking about a programming career: professional programmers have to learn this stuff (I'm still learning myself). For those who dislike OOP, you're still going to have to learn it properly in order to argue convincingly against it. There is no escape![]()
I'm an OOP advocate, but I DO NOT believe that OOP is almost always a better and more powerful tool.OOP advocates aren't bigots: but we do believe that OOP is almost always a better and more powerful tool and also that this isn't just a question of style but rather a fact which can be demonstrated.
Are you then implying that my knowledge of this is lacking?We do think that people who argue against this may not have fully grasped what is after all quite a difficult discipline (and I make no claims to be an expert myself). These are strong words I know which require to be backed up by strong arguments. I can understand if that can be provocative to the other camp.
Take from that what you will, but if you really read some of his other rantings and come back to comments by Tony Marston, you begin to see what their frustration is. Furthermore, notice that his last couple of sentences talk about complex data types. This is an area in the PHP community where I hear very little talk. And not just of complex data types (data structures), but algorithms as well. So if we just tell all noobs "Learn OOP and prosper", we are ultimately doing them a disservice. Without a clear understanding of this topic and it's ramifications, then it's inevitable that the thing Tony Marston complained about will come to pass in the practice of these developers: An extension of an OOP centric view to data management.Fabian Pascal wrote: Like object DBMS before it, XML has all the hallmarks of becoming the next industry fad, among them proliferation of articles, books and conferences on the subject and vendors stepping over each other to provide some sort of XML "support". Well, to a hammer everything may look like nails, but whether programmers and web developers like it or not, the fact is that not everything is nails and treating everything as nails will not work. A DBMS is not program and a data language is not a document description language and there is ample knowledge and experience to show that treating them as such causes severe problems. Unfortunately, programmers and web developers are not familiar with data management fundamentals. Those forgetting the past are doomed to relive it.
Because XML is advanced as a data management solution, the only way to assess its suitability to task is from a data management perspective. One particular kind of XML support are DBMS "extenders", a form of so-called "complex" data types (documents). This is the DBMS vendors' response to criticism of RDBMS (more precisely SQL DBMS) products as poor supporters of such data types. Unfortunately, the data type concept is one of the least understood even by database practitioners. This is both the cause and the consequence of the failure by SQL and its commercial implementations to support relational domains, which are nothing but data types of arbitrary complexity. Without a good understanding of data types it is impossible to assess any implementation of "complex" types, be it XML or any other types....
Indeed.McGruff wrote:The point is that one or other - or both - of us, or anyone else reading these public discussions, might have something to learn. That's what we're here for. That's what discussion should be all about.
He posted on 12 November on page 2 of this thread:jl wrote:What happened to Roja?
Roja wrote:I'll leave this discussion, as I think the salient points have been made, and to avoid further miscommunication.