Posts Tagged ‘php’

PHP Has An Identity Crisis

Sunday, January 11th, 2009

I have been using PHP for quie a while. I first learnt PHP 4 when I was 18-19, building a dynamic art gallery type site for my drawing attempts. I thought it was wonderful that I could programmatically display new images without having to update the HTML file. I also used PHP for my final year project in university, and by the time I graduated, I was quite proficient in it.

However, as I slowly got more and more interested in programming, and the principles of programming, I learn more and more languages, and learnt OOP practices that I never applied to PHP, simply because I was self taught, and at the time PHP wasn’t pushing itself as an OOP language.

However, times change, and the PHP community tends to push the fact that PHP is an OOP language. Firstly, this isn’t entirely accurate. PHP is a language that supports OOP, however it isn’t an OOP language. There is no string object – I cannot take a substring of a string by calling a method on the string variable. Instead I must use a global function substr() to do it. That’s not OOP, it’s procedural wrapped in OOP.

However, PHP does support OOP. You can define custom classes, you can create objects and you can call methods on that object. In a hostile world full of more OOP languages like Ruby and Python that are gaining traction in the web development world, PHP must push more and more it’s OOP support. If you talk with serious developers in the world of PHP, they will insist that although PHP is not inherently an OOP language, it’s close enough.

Today I found out that from PHP has introduced in PHP 5.3 the GOTO statement.

For those of you who are unaware of the specifics of the GOTO function, this post, also the post that I learnt this fact from, outlines it. While experienced programmers know enough to avoid the GOTO statement, new programmers may not, and PHP can be abused enough already without the GOTO statement.

So, what is it PHP? Are you an OOP language, or are you procedural? The PHP community pushes it’s support for OOP, and then it introduces a control statement that characterises the worst of procedural code. PHP needs to clarify it’s future as a language, and decide whether to push itself as an OOP language or as a procedural language.

Encapsulation in Python

Saturday, January 3rd, 2009

Or, “I see London, I see France, I see Python’s underpants”

I come from a primarily C# background, where I have fairly tight control over how visible my properties and methods are. I can choose to make them private to the class, protected to the class and it’s children, internal to the assembly or public for everything.

In my course of learning Python, I’ve discovered awesome things like docstrings, multiple inheritance and sequence unpacking. However, I’ve also been shocked and made more than a little uncomfortable by the realisation that Python doesn’t implement encapsulation. I don’t trust other people not to abuse access to methods that I’ve intended to be private – I’ve seen too much bad code for that. While I know there are ways to get around this, I don’t feel I should have to perform code gymnastics to implement what I feel is an essential part of an OO language.

Another thing that makes me cringe a little about Python is the need to pass in the self parameter for all object methods. I realise that this is required to differentiate between an instance method and a class/static method, however I just can’t shake the idea that it seems a little clunky, even though I know it’s no different from writing a static at the start of my function definition.

However, to wrap up the last two weeks, I feel confident in saying that from what I’ve seen I like Ruby more than I like Python. That’s not to say these are bad languages; I first learnt web based programming with PHP, and I’m sure that I’m going to leave PHP in the dust for one of these two languages. I will also disclose that I did not learn Python 3.0, and haven’t really looked into it whatsoever, so if 3.0 changes some of the stuff here, forgive me.

Having said that, I will investigate both languages more, and definitely work in both more. I’ve found PHP doesn’t do it for me anymore, I’ve seen a better side of programming where I don’t have to live with ugly warts in my languages, and PHP is ugly. Long live Python and Ruby.