Hall of Famer

Looks like nested class is also on RFC now, things are shaping up faster and better than I originally thought: https://wiki.php.net/rfc/nested_classes

As far as I know, you need 2/3 of votes, so thats about 66.7%. It seems to me that property accessor gets 34/56 last time, which is about 60.7% of the votes(6% lower than required). Perhaps BC was the cause of all these, wonder if its possible to re-vote or that whatever gets rejected will never be re-considered.

I actually like the extended keyword support a lot, its not for me to decide which feature gets past the voting phase though. Varadics have already made it to PHP 5.6, so its not really an issue here. Come to think about that, it seems that C# accessor methods gets rejected despite more than 60% of the voters said yes(it needs to make 2/3 or more). I doubt if this means that this idea is dropped forever, or that the RFC creator can still make a comeback by making some major/minor modifications of the initial proposal. I personally like to see accessor methods implemented in PHP, but life is not much tougher without it so I can live with that.

Thoughts? https://wiki.php.net/rfc/anonymous_classes

Of course I know what is an IOS and what is an OSX, I was referring to the 'home screen' which I still call it 'desktop' at times since I'm so used to this term after being years of laptop/desktop computer user. Shall we move on from such debates that hardly even matter at all?

same reason why iOS changes its desktop design everytime. No matter whether its even a better design than its predecessor, a change is a change, and people want to see changes.

Actually Id recommend Java or C# for desktop applications, they are more object oriented languages than C++, while C is only useful for operating system as its procedural and lacking even the most basic object support.

Well Id recommend against using singleton database connection, but if you are using it as a learning process for programming/OOP its perfectly fine. They really are not OOP, but its still good to know how to deal with them as you may encounter programs from other coders that use statics/singleton if you work in a team. Still, keep in mind that static methods/singleton methods are poor OOP practices, use them sparsingly.

Nope I am not being overly defensive, I do in fact know what I am doing, and in fact if you read Ignace's post history with me you will know why I am talking about this. There was a time when I brough up that PHP's namespace is lacking wildcard import by using a draft user class hierachy example to illustrate how importing multiple classes can be made easier, and Ignace went on to comment on how the user class hierachy is flawed. Dont you think this is completely missing the point of dicussion?

I said it was just for illustrative purposes, if you earnestly believe this is what I will end up having in my own OO architecture you'd be serious mistaken. In my OO design Id completely separate the domain layer from application layer, the domain model will not know how to handle redirection, login and this kind of behavior. The controller will call login based on the subclass of model, but then you need to create a class hierachy for controllers first, maybe service layers too if you need further separation of concerns. Also I wont use PDO to fetch objects in the application layer either, instead I will use a data mapper. Now you see it will require significant overhead, and thus inappropriate in a single post like this to explain. Yeah I will do it if it were my own application, but here I just want to explain the concept of polymorphism, more precisely how to use polymorphism to eliminate conditionals. Nothing more nothing less, I dont wish to write 20+ classes/interfaces to scare the OP away, perhaps this forum wont allow me to post/upload all the source code of these classes anyway since they will be too long. Like I said, you can always refactor after design the first draft of your system architecture, for OP's skillset the above code should suffice, once he learns more about OOA/OOD he will move on to more advanced OOP.

Your design has some flaws in it. First of all, mysql extension is deprecated, use mysqli or PDO. Second, for a system like this Id prefer object oriented approach as you are not handling a personal home page type of website. I dont get the entire picture of what your site is supposed to do, but below is a sample code that will help(note it is not a complete design, you can do some refactoring to make it better, its used for illustrative purposes only): abstract class User{ public function __construct(UserDTO $userDTO){ $this->id = $userDTO->idnumber; $this->idNumber = $userDTO->idnumber; $this->password = $userDTO->password; // Assume you already did password hashing/salting beforehand $this->position = $userDTO->position; // Whatever additional fields } abstract public function redirect(); } class Admin extends User{ public function redirect(){ header('Location: admin.php'); } } class Teacher extends User{ public function redirect(){ header('Location: teacher.php'); } } class Student extends User{ public function redirect(){ header('Location: student.php'); } } class Cashier extends User{ public function redirect(){ header('Location: admin.php'); } } class UserFactory{ public function __construct(UserDTO $userDTO){ $this->userDTO = $userDTO; } public function createUser(){ $method = "create{$userDTO->position}"; $this->$method(); } private function createStudent(){ return new Student($this->userDTO); } private function createTeacher(){ return new Teacher($this->userDTO); } private function createAdmin(){ return new Admin($this->userDTO); } private function createCashier(){ return new Cashier($this->userDTO); } } // Assume you have a PDO object available, but not a data mapper(for a small system). $PDO = new PDO(/*.. Your DB credentials..*/); $stmt = PDO->prepare(/*.. Your SQL ..*/); $stmt->execute(); $userDTO = $pdo->fetchObject("UserDTO"); //UserDTO, a data transfer object $factory = new UserFactory($userDTO); $user = factory->createUser(); $user->redirect(); exit(); This design is better 'cause you can use polymorphism to eliminate unnecessary conditionals. The advantage is more evident once you have to write duplicate if...else statement to check user level/position in other script/class files. Also once your site grows, there is a good chance that you will have other actions beyond redirection that will require checking the user level/position conditionals. All you have to do then is to add such method for each User sub-classes. As you see, with Polymorphism, you dont need to worry about writing these conditionals over and over again, PHP will do it for you. Note the design can be further improved using a domain model - data mapper design pattern, you will learn this later once you become more familiar with PHP and OOP.

A perfect script is a script with both perfect functionality and perfect design, they are about equal importance. The functionality part is easy to understand, it is about how your script works and meets the feature-requirement of your clients while staying bug-free. This does not have much to do with OOP, you can write in OOP while your code is full of bugs/syntax errors and do not meet the requirement of your clients. This is why I said OOP is one necessary step to perfect script, but not that OOP = perfect script itself. The design part is where OOP truly fits in, a perfect design = fully object oriented design. A perfect design means that your script is easily reusable, extensible, mainteanable, unit-test friendly and professional, which is exactly the definition of a fully object oriented design. A fully object oriented design also requires more than just the use of objects, as its possible to use objects without abstraction, encapsulation and any other related OO features, which make a script truly procedural in disguise(such examples are Singleton and Transaction scripts, two infamous antipatterns). However, without using objects you cannot achieve fully object oriented design in the very first place. You can mimic OO features using procedural language constructs, they just dont work as well as using actual objects in an OO language. In a word, using objects is a necessary condition for fully object oriented design, and fully object oriented design is a necessary condition for perfect script. Applying the basic of logics, we arrive at using objects is a necessary condition for perfect script too, which then translates into 'in a perfect script everything is an object'. No one is perfect, nor can a programmer write a perfect script, but you can always approach perfection as close as you can. This is why I emphasize the use of objects in PHP projects, the fact that you cannot write perfect script does not mean you should not aim at improving your script. In fact, even a tiny step will help.

Well if today's programmers want objects, theres definitely a reason for it dont you think? After all, all large enterprise applications/softwares are object oriented, these professional developers dont choose OOP just for its name. You know, in a perfect script everything is an object. Sure you can never be perfect, but you can approach as close as you can by writing more object oriented code(not just by using objects alone, a point amateur coders usually dont grasp). Same reason why engineers are always attempting to improve a system's efficiency knowing it can never be 100% efficient.

Well the entire procedural style of connecting to MySQL database(mysql_connect() or mysqli_connect()) is outdated, instead using the object oriented syntax for MySQLi or PDO is the way of future. Use this for your development assuming you prefer MySQLi over PDO: $mysqli = new mysqli('localhost', 'my_user', 'my_password', 'my_db');

Doubt you really dont care as you replied to this thread, and twice. Anyway, why not get back to the topic and come out with a list of programming practices that aspiring OOP programmer should avoid or get rid of? Thats the purpose of the thread to begin with, I aint interested in arguing on the irrelevant matters anyway.