From Java to PHP
From Java to PHP
Join the DZone community and get the full member experience.Join For Free
Learn how Crafter’s Git-based content management system is reinventing modern digital experiences.
We are welcoming some new colleagues that come from a Java background in the Onebip team, both from the development and operations field. Here's a primer on learning PHP in this situation, that you may find useful when introducing similar people in your PHP-based projects.
The absolute basics
Before being able to discuss meaningful matters over PHP code, these pages from the manual should be sent to each interested developer.
- What is the basic syntax and the available data types of PHP. Primitive types are diffused like in Java, but there's no autoboxing as there is no object equivalent for them.
- Strings are immutable and one of the most important types. They can be defined with single or double quotes, and their manipulation functions follow the C api.
- Arrays are the glue of the language, working as lists, sets and maps while wrapped into objects. They can always be traversed with foreach(), and keep an eye on the available functions to avoid rewriting array_search() or sort() by accident.
- Operators work differently on primitive values and on objects: == is different from === in both these context, but in two ways. Other everyday operators are `.` and `+=`.
- PHP's object paradigm is borrowed from Java: it supports concrete and abstract classes, interfaces, and the private, protected and public scopes.
- Type hints (which are actually not hints but strong preconditions) are what is most similar to Java static type safety mechanisms. I personally strongly favors their usage.
- Namespaces are packages, use statements are imports. However, you don't always have to write them.
The deployment model of PHP consists of an interpreter instantiated N times, running on many shared nothing processes.
Don't care about:
The installation process of Apache and PHP: if you work in a team, you will get good help on that, and you're going to do this only once per project probably. For example, we provide a virtual machine ready for development.
The function syntax is also not very useful by itself in 2013, skip directly to objects and their methods. Take a look at anonymous functions, however.
Exceptions work mostly as in Java, so don't bother reading about them before coding.
Sessions are also evil in web services nowadays, so ignore anything that start with $_SESSION or session_*(): write shared nothing services (that may be restricted to our team and projects.)
In general, ignore also low-level APIs like setcookie() or exec() if you already have an higher-level abstraction in the application you're working on, being this abstraction a library or your own code. It's important to know how cookies are transmitted according to HTTP, but coming from another language you already know the protocol.
So you write objects that go into a graph
At least that's how I see programming these days. However, you have to exit the process sometimes, and PHP provides several APIs for that.
- The database APIs such as the mongo and PDO extensions, working respectively with MongoDB and relational database. However, if you already use a database abstraction layer, learn just that as there is nothing interesting to see at this lower level.
- The DateTime object and its cousins, at least know how to call its constructor and the format() method.
- You should know these APIs exist in order to look them up on demand: json_*() functions, the SimpleXMLElement class, the mcrypt extension and hash_hmac(), mail(). They're just a click away at php.net/function_or_class_name, and I think these names are pretty self-explanatory to tell you when you should read about them.
Watch out for:
Some topics are always controversial, and get confusing for PHP beginners. Raise your alert level when you feel you're encountering some strange behavior.
- the difference between == and === comes out often, and it cannot be reduced to "just use === by default" since all primitive types coming from HTTP requests in the classic x-www-form-urlencoded Content-Type are usually strings.
- php.ini settings may change the output of your application and the actual flow of execution depending on error reporting levels and display options. One never ceases to learn, so when you encounter some problematic directive, take a quick read of the rest of the directives for that extension.
- Since some people believe web development is the concatenation of strings (it is not), it is tempting to reinvent the wheel; for example, writing functions for composing URLS from paths and query strings. http_build_query() solves that problem as other Composer-ready packages do, so take a look around before starting to implement commodity algorithms yourself. Stack Overflow and the PHP manual itself are good places to start if your problem has been already solved by someone else in the last 10 years.
Perform a kata
To test your level of proficiency with PHP, execute a small kata with TDD which incidentally will also check your usage of PHPUnit.
For example, classic katas are:
- The Fizz Buzz, maybe with a web interface.
- The Roman numbers kata: write a function that transforms 42 in XLII.
- The Game of Life, although it is probably too complex for your first PHP project if you didn't already solve it in another language.
Opinions expressed by DZone contributors are their own.