Hall of Famer

Well I am just using this as a quick example in which you may have a series of classes from a namespace you wish to import quickly into another namespace. And now you spent an hour writing useless criticism just for explaining how that user system aint working, its completely missing the point I was arguing early on.

But its a really useful feature PHP is missing, not like the syntax which is simply a matter of opinion. Assume you have a UserFactory class to decide which type of user object(Member, Admin, Banned and Guest) to instantiate, all of these user classes are in the subpackage Model\User. You will have to write this many lines in PHP: use \Model\User\Member as Member; use \Model\User\Admin as Admin; use \Model\User\Banned as Banned; use \Model\User\Guest as Guest; In java, all you have to do is to write this line: import Model.User.* See how life can be made easier? Sure it may not seem to be a problem when you only needs to import one namespace with four classes, but what if in your controller class you have to import like 5 namespaces and 30+ classes? It will be quite a mess I must say. Yeah at times it may be helpful, but you have to agree that its so inflexible. There are more occasions you need to import multiple classes from a namespace than dealing with conflicting class names, and PHP aint good at handling this since you can only import one class at a time.

Well its been a while since PHP added namespace support, but so far its still crappy. I am not sure if this has been changed in PHP 5.5, but at least in 5.3.18 and 5.4.9 you cannot do this: namespace A{ class Foo{ public function bar(){ echo "foo bar"; } } } namespace B{ use \A; $a = new Foo(); $a->bar(); // This results in a fatal error! } Instead, you either have to use the whole namespace name or just import classes in a package one by one: namespace B{ $a = new \A\Foo; $a->bar(); // outputs foo bar; use \A\Foo; $n = new Foo; $n->bar(); // outputs foo bar; } This results in a serious problem when you wish to import an entire sub-namespace. In a real application its unlikely you only have one Foo class in the namespace A, so you have to write multiple lines of use statement to import all these classes, which can be quite annoying. You may argue that Aliasing is here to serve the purpose, but honestly aliasing is only useful in a really complicated system with namespace as long as 'Application\Model\User\Member\Profile\ProfileField\AboutMe'. In most occasions aliasing is just as much typing as using the entire namespace name, and serves no practical purpose. You know in Java you can import a package of class using something like 'import javax.swing.*', no idea why in PHP its not possible. Or maybe its already available in PHP 5.5? I dunno.

For me its definitely PHP4 code. Come on its been more than 8 years and some libs are still trying to be friendly and compatible with this old dinasour.

Well if you have strong programming background in other languages in C++, Java or C#, it shouldnt take more than 3 weeks for you to grasp PHP. If you indeed are, I have to warn you that PHP is not as much object-oriented as these, so some old habits need to change.

Well actually many webhosts such as HostGator and Bluehost already enable PHP 5.3 as an option for users, although the default version is still PHP 5.2.17. Users can edit or add a line in config file to use PHP 5.3. For freehosts you cant really help, some do not even have a working PDO lol.

Well I am designing a software to be used by many users who may have freehosts, sharedhosts or VPS. There are some awesome features only available in PHP 5.3 I want to use for my softeare, such as namespace and about 80% of DateTime methods. A problem is that a few users still have hosting packages that run with PHP 5.2.17, but I wonder if it is about time to drop support for these PHP 5.2 users? I mean, is it a good practive to require users to have PHP 5.3+ on their server for application design nowadays? What do you think?

Come on you people just confused the OP. He already found his answer a while ago, the direction is to use a fully object oriented approach. Thats the way of future, dont you agree?

Well why still arguing in this thread? I thought the OP already got his answer, which is to use OOP. This way he makes a much much more professional and maintenable site. Is this what hes trying to accomplish, isnt it?

No worries, if so I am more than certain that you should be using OOP, a non-amateur programmer should be fine with OOP and should stick to it. PHP is much more similar to Java and C#, although C++ is not that much different. Can be a bit tricky if you are so used to using friend classes/properties/methods though.

Well if this is your first time into web development, you'd probably want to start off with procedural programming unless you really know what you are doing with PHP. I do recommend you to learn OOP while developing your site, since it is one huge step for amateurs to turn into professionals. Someday you may want to go full OO once you are good at it, and that your site gets bigger and more complex. Good luck, theres always enough to learn in the world of programming.

Here's one: http://umumble.com/blogs/php/249/ But anyway, its not a really big deal. I was just wondering if there was a particular reason to use Twig instead of Smarty, you have answered my question. Guess it makes sense if the developer for Symfony and Twig is the same guy.

umm why? I do not see this is a problem. You pass whatever parameter into the object as you want. It works out with not only object without arguments, but also situations in which your arguments are integers, strings or boolean values. An example is given below: class Foo{ public $string; private $integer; public function __construct($str, $int){ $this->string = $str; $this->integer = $int; } public function getInt(){ return $this->int; } } class Bar{ public $foo = new Foo("This is a string", 1); public function print(){ echo $this->foo->string; echo "<br>"; echo $this->foo->getInt(); } } $bar = new Bar; $bar->print(); // prints "This is a string" in line 1, and "1" in line 2. Well yeah, it can get tricky if your object properties need variable arguments, it can also be achieved using dependency injection.

Surprised that I did not come across a discussion thread here, so I decide to bring one up. Looks like lots of solid additions, although it does not look as exciting as PHP 5.3 and 5.4's initial releases. Whats your thought? I was expecting syntax like this below to be made possible in PHP 5.5, too bad its not happening and we still have to use the constructor to initiate properties as objects: class Foo{ } class Bar{ public $foo = new Foo(); }

Just curious. Smarty has easier syntax and is actually slightly faster than Twig in many circumstances, are there any other significant advantages Twig provides but Smarty aint? Or is this just a matter of choice made by Symfony developers?

Of course OOP, unless you are building an amateur fan site. OOP is the standard for quality programming, and since your site actually has online-payment Id say you will need such professionalism. In a perfect script everything is an object. You cannot be perfect, but you can approach as close as you can.

Id say sitepoint and devshed are good sources for web developmnt news and tutorials. There are some awesome stuff on Phpfreaks and PHPbuilder's homepages too, you can take a look.

Well if all your script does is to output one line of sentence to your users such as echo "hello world", or echo "Welcome to our site", then why not just use plain html? XD

lol are you sure about this? In my application each database table has one class that wraps the data and performs certain actions, I thought it was already way too much. Six sounds like an overkill to me, but perhaps Symfony has them for different uses?

Well in my application the private message database table stores the following info: mid: Message ID sender: The sender's info recipient: The recipient's info title: Message Title text: Message Context datesent: The date message is sent status: Unread or Read(users are notified by unread messages from a widget at sidebar) folder: The folder a private message is stored in. Can be Inbox, Outbox, Draft or user created folders So yeah, it really depends on how complex your PM system is gonna be. You can start off with a simple design, but make sure it is extensible and reusable so you can add new features every now and then. If you have other types of messages such as Visitor Message(profile comment), Shoutbox Message and System Message, it will be a good idea to use strategy design pattern.

Yeah, it is perhaps not even necessary to worry about PHP 5.2 compatibility nowadays. PHP 4 was great while it lasted, but now it's totally out of date. Most popular frameworks do take care of 3rd party modules integration pretty nicely, although they do it in a quite different way. The aspect of third party script integration is not that important for framework selection, but that's just my opinion.

Just got the book PHP Master: Write Cutting Edge Code, seems that it can be quite good for intermediate skilled programmers' further improvement. Whether a book is suitable for a specific coder is a difficult thing to say, everyone is different.

It seems to me that Symfony 2 is quite successful so far as PHP framework, has the potential to beat Zend Framework. Nodejs is getting more and more popular too, I wonder how big a difference it can make.

I use cuteftp, but for some reason it disconnects after about half an hour or an hour so I have to reconnect then.

Well PHP is still the most popular web programming language at this point. It is relatively easy to learn for beginners, and its syntax is similar to C++/Java so those who have desktop application development find it easier to get used to PHP. Not mentioning PHP is specialized to code in dynamic web pages. So yeah, there is a reason why PHP is popular and will be popular.