mysql_connect() deprecated?

[agent_404]

Hi. I've been posting in some forums regarding the use of mysql_connect() and it seems some people are saying that mysql_connect() is deprecated or "rather outdated" and that I should be using mysqli_connect() instead. I've  and it does not say that mysql_connect() is deprecated. Does anyone know if it will become deprecated any time soon? Is there a list of soon-to-be deprecated PHP functions anywhere? Is it still safe to use? Other than support of object oriented code are there any great reasons to use mysqli_connect() vs mysql_connect() for procedural coding? Thanks!

[mikosiko]

http://www.php.net/manual/en/mysqli.overview.php

[Aziz]

Zend is planning on removing it sometime afte version 5.5.x, if your codebase is small you can modify the code to use PDO or MySQLI. Alternatively, if your codebase is hard to change (or too big to change) and you still want to upgrade your PHP version, you can use wrappers like this: http://www.phpclasses.org/package/8221-PHP-Access-MySQL-databases-using-PDO-wrapper-functions.html

[Barand]

 I've  and it does not say that mysql_connect() is deprecated.

 

 

 

read first paragraph - http://php.net/manual/en/intro.mysql.php

[kicken]

I've  and it does not say that mysql_connect() is deprecated.

You must be blind, because it's pretty hard to miss:

[mac_gyver]

probably not back in June 2011 when this thread was started

[Irate]

Lovely, seeing old threads like this getting necrobumped out of nowhere.

[Hall of Famer]

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');

Edited September 10, 2013 by Hall of Famer

[vinny42]

 

 using the object oriented syntax for MySQLi or PDO is the way of future

 

It's certainly true that today's programmers want objects for everything, regardless of wether it serves a purpose.

[Hall of Famer]

It's certainly true that today's programmers want objects for everything, regardless of wether it serves a purpose.

 

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.

Edited September 10, 2013 by Hall of Famer

[vinny42]

 

Well if today's programmers want objects, theres definitely a reason for it dont you think?

 

That's the "everybody else does it so it must be good" defense. :-)

Lots and lots of people use MySQL so it must be a good database, yet 2013-02-31 is a perfectly valid date according to MySQL.

 

 

After all, all large enterprise applications/frameworks are object oriented, these professional developers dont choose OOP just for its name.

 

Large enterprise applications use OOP because OOP solves the biggest problem they have: organising the code into managable chunks that can be expanded on without breaking the design contracts. And even in those applications there are lots of classes that became classes only because all the rest is in classes, not because someone sat down and examined things like performance and resource usage.

 

 

You know, in a perfect script everything is an object.

 

That's what you and a lot of other people seem to think, but why?

[KevinM1]

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.

 

What constitutes a perfect script? When you can answer that intelligently, you might begin to understand why people continue to take issue with your blind fanboy rambling.

[Irate]

 

What constitutes a perfect script? When you can answer that intelligently, you might begin to understand why people continue to take issue with your blind fanboy rambling.

 

 

Nicely countered.

[Hall of Famer]

 

What constitutes a perfect script? When you can answer that intelligently, you might begin to understand why people continue to take issue with your blind fanboy rambling.

 

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.

Edited September 10, 2013 by Hall of Famer

[Barand]

HoF, you're not an OOP Prior are you, complete with a big stick topped with a glowing orb and everything?

[KevinM1]

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.

What about functional programming? What about environments where the overhead of creating and tracking objects make OOP unsuited to the task? Why can't procedural code work as well?

 

OOP is certainly not ideal from a computing POV, with its overhead.

[vinny42]

 

A perfect design means that your script is easily reusable, extensible, mainteanable, unit-test friendly

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. 

 

It sounds to me more like you have very little  experience with procedural code and you just ignore that possibility that the things you've just named as requirements for your illusive perfection don't always exist in real life, let alone that most of them can be achieved in procedural programming with very little effort.

 

Sir, your arguments have no substance!

[Muddy_Funster]

I love these rants from HoF, Completly unsubstantiated opinionisation floated on a pretext of obtaining perfection. 

 

The design part is where OOP truly fits in, a perfect design = fully object oriented design.

I have to argue that perfect design = most efficient design. whether it uses objects or not.  Being able to acertain the benifits of all paradigms in a given scenario and impliment the best one acording to the given case and requirements is far closer to design perfection than simply running about the room shouting "object! object! object!" - in my opinion anyway.

 

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.

That may be the definition accoring to your "Bible of the OOP Evangelist", but in actual fact it's nothing more than an opinion.  For future refference, if you are seeking deffinitions you should try a dictionary rather than scripture :

 

http://dictionary.reference.com/browse/object-oriented+design

object-oriented design definition

programming
 (OOD) A design method in which a system is modelled as a collection of cooperating objects and individual objects are treated as instances of a class within a class hierarchy. Four stages can be identified: identify the classes and objects, identify their semantics, identify their relationships and specify class and object interfaces and implementation. Object-oriented design is one of the stages of object-oriented programming.

 

 

... However, without using objects you cannot achieve fully object oriented design in the very first place.

Really? Who knew?

 

You can mimic OO features using procedural language constructs, they just dont work as well as using actual objects in an OO language.

You kind of have that backwards given the evolution of high level programming languages over the years. OOP has maintained features that were originaly created by the use of procedural paradigms

 

 

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.

 

In a word?? Which one exactly?

 

PHP is not a natively OOP by design.  And it shoudn't be anyway.  If PHP was an entierly stand alone language like java or C, when the only interaction you need to code for is with other constructs of the same language, then a pure OOP structure is fine and dandy, and if you are running PHP as a stand alone language from the console the same applies. Most people who use PHP, however, use it as a web based scripting language, where the day to day activity of the script is dependant on interacting with multiple non-object languages on various levels. XML, HTML and Javascript are not given to nativly support object transactions, yeah you can use JSON to force objects here and there, but at the end of the day, your just going to have to burst that object appart later on to make it useable.

 

My humble opinion is that you are harming your code, and your reputation, with the "OOP zealot" mantra you have adopted.  Turn the Church of OOP audio book down from 11 and try opening your mind a little, or at least expand it a bit more before trying to pass off your ideals as proven fact.  Just because you preffer OOP does not meen that every other paradigm is bad. 

Edited September 11, 2013 by Muddy_Funster