Some quick translations, OO PHP to C#

So a recent project has facilitated me brushing up on my C# – so I thought I would share some basic translations of things that can be frustrating when you know the usual programming principles (object orientated programming), but not all the syntax.

A quick couple of points to note:

  1. C# is a strictly typed language, that means you have to know about what your variables are going to be, and yes, you have to declare them somewhere sensible
  2. Accessing methods and properties within your class does not require usage of $this – you’re talking about true scope of variables and methods, so you don’t have to worry about it
  3. Public, protected and private are essentially the same
  4. You have to declare the return types on every method, none of this return an object or false stuff
  5. Namespacing is essentially the same as if you were following the PSR-4 standard
  6. Everything, including strings, are objects
  7. A single quote and a double quote are fundamentally different things

Declaring a variable

Okay, so starting with the basics, declaring a variable is basically the same, except you have to declare the type, so declaring age as a variable, integer, with the value of 25 would look like this in PHP:

$age = 25;

However, in C# it would look like this

int age = 25;

Moving into this being a property in a class, you must rather than optionally, or have to if you’re conforming to PSR-2, so in PHP it looks like this

public $age = 25;

In C# it’s going to look like this:

public int age = 25;

Declaring methods

Okay this is an easy one in PHP, it looks something like this. Using PHP 7.1 we can strictly type the return.

public function myMethod(MyClassOne &$argumentByReference, MyClassTwo $argumentByValue) : ObjectClass

{

    // Do something in your method here

}

// This would be called by doing something like
$object->myMethod($parsedByReference, $parsedByValue);

This one gets slightly different when translated into C# for a couple of reasons. You must declare the types of the parameter, the type of the response(s), it also gets a bit different when calling the method too:

public ObjectClass myMethod(ref MyClassOne argumentByReference, MyClassTwo argumentByValue)

{

    // Do something in your method here

}

// Now calling your method would look slightly different

Object.myMethod(ref parsedByReference, parsedByValue);

Using Objects

Instantiating objects isn’t much different either, really; it looks different but that’s because it’s strictly typed.

Main difference between use statements in PHP and C# (other than that it is using in C#) is that you use a namespace, the classes contained therein (this namespace only, not its children) are automatically available.

In PHP I want to include a class and then instantiate it, will look something like this:

use Vendor\Project\Namespace\ClassName;

// Then you have all of your usual declarations, which we'll get to

$myObject = new ClassName();

However when you want to do this in C# it looks something like this:

using Vendor\Project\Namespace;

// Then all of your usual declarations

ClassName myObject = new ClassName();

Declaring Classes, using Inheritance and Interfaces

This gets a bit different, but only syntactically. We’re going to create Person as an abstract class, this will be extended by the Employee class. Employee is going to implement an interface called Emailable.

For the sake of ease I’ve not separated these into different files

In PHP it would look like this:

abstract class Person{

    // Shared functionality here

}
interface Emailable{

    // Interface requirements here

}

class Employee extends Person implements Emailable{

    // Employee functionality, including Emailable requirements, in here

}

In C# however it would look like this

namespace ObjectOrientatedPrinciples.MyExample
 {
    abstract public class Person
    {
        
    }
    interface Emailable
    {
        
    }
    public class Employee : Person, Emailable
    {
        
    }
 }

You will see from this that C# doesn’t necessarily draw the distinction between classes being extended and interfaces being implemented.

Arrays and Lists

This is actually the only thing I found to be a little bit painful, however there is a decent tutorial on arrays on the Microsoft Developer Network (MSDN)

Closing Off

I’ll leave it at that for tonight. But a quick few bits that I thought might help someone out, it would’ve helped me if I could’ve found this article this morning. Though admittedly probably only saved me an hour or so. Not the point though, here it is 🙂

Tips for commercial WordPress, and open source, development

Hi everyone

So I’ve been using content management systems on and off for the best part of 10 years. From the by-gone days of PHP Nuke and when content management systems like PHP Fusion were all the rage. To using more modern, and definitely more widely adopted systems like Joomla and, of course, WordPress; and just to throw other open source stuff into the mix, platforms like Moodle.

Now I’ve returned to using WordPress on a daily basis, but from a different perspective; I don’t do too much development on WordPress personally; my skill set generally lies in building things on frameworks such as CodeIgniter and Laravel, if not bespoke. But I do use WordPress to the extent of managing multisite installations, managing production stability and servers, as well as deployments and migrations.

Having been in the unique position to pick up some legacy code in my time, and seen what does and does not make a WordPress site easy to work on, manage and maintain; I thought I would put together some tips for building WordPress sites, and functionality, which will stand the test of time.

1. Never modify the core

This is a deadly serious one. No matter what you’re working on it should have a specific way of extending functionality, whether through plugins and themes, extensions or a specific namespace where modifications should be added, never, ever, ever modify the core. The same applies to the core code on a plugin.

The reasons for this are really simple; you probably don’t know and understand the full architecture or what you might break by changing this, and more importantly the biggest strength of using something open source is that updates are generally frequently available. The moment you change something in the core you’re going to sabotage any upgrades; you will have to make the choice. Either update the software (absolutely critical) and lose your changes, or don’t update the software and risk leaving bugs, security vulnerabilities, and all kinds of other stuff in there. Not a good position to be in.

2. Choose the right one

WordPress is the most widely adopted content management system in the world. Impressive, right? And technically, yes, anything can be built on it. In the same way any system can be built using .txt files for data storage. It can be done, but that doesn’t mean it should be.

I’ve laboured this point a few times in a few articles and things, but a good developer will know the tools available to them and choose the best one for the job. It is worth spending six months for a content management system and blogging platform, that does exactly the same as WordPress? Of course not. Is it a good idea to build a secure intranet containing sensitive data about national security on WordPress? Of course not. It’s about knowing what’s available and making the best decision based on this.

This is a difficult one, however, as you need to choose the one that fits your needs right now, as well as being compatible with the long term visions of the site; or know from the start that a rebuild will be necessary.

3. Be wary of plugin dependencies

Why use plugin_function when cms_function does the same job, and is probably going to be better supported in the future? When installing plugins, extensions and add ons; always think about the eventualities? What if this plugin’s core is compromised and I need to disable it right now; what will break? What if the plugin stops being supported? How tied into using it am I right now? If you’re managing lots of websites, especially; be wary of the headache you’re going to have if you’re relying too heavily on too many plugins.

If you notice yourself using plugin X on every site you build, or relying on it super heavily, it might be worth doing one of a few things. Either building your own replacement, so you’re in control of the core. Or perhaps wrapping it in your own functionality, so if you want to swap it out, you can. Using a technique called Facading can help with this, hiding plugin functionality behind you facade means you can swap what’s behind the facade out if you need to.

Really the point here is don’t install things willy nilly, think about the dependency you’re creating on this plugin for your website, and how much of a pain it’s going to be if you want to remove it.

4. Always check the source

Depending on the project and the size reading the source code line for line probably isn’t going to be efficient; so that’s not what I’m suggesting here. By source I mean the author, the factory, the company; wherever it comes from. Make sure they’re trusted, WordPress, for example, examines all of the plugins and themes submitted to their public repositories and they’re pretty stringent on their standards, as well as ensuring they’re safe (from a security standpoint).

Most mainstream CMS have white hat security scanning tools that will uncover most, if not all, known security flaws and vulnerabilities. Running these can only be a good thing, as long as you act on the results you get.

5. Don’t be afraid to code things from scratch

There might not be a plugin which does what you want, or doesn’t do exactly what you want. You have 10 requirements from your client. Plugin X fulfils 9 of them. Do not try and hack it to fulfil the 10th, it will only go badly; honestly, I’ve been there and done it a bunch of times.

Just because you usually use X plugin and Y CMS, doesn’t mean you have to this time. Some things are best built from scratch, whether the whole site/software, or a specific functionality. Sometimes the best option is to get stuck in with coding the thing you want. You’d be surprised at how quick this can sometimes be. And just because your CMS offers a specific functionality doesn’t mean you have to use it. WordPress Custom Post Types are a beautiful example of this, as well as their taxonomies. These are both beautiful pieces of functionality; but they’re not the best way to store bespoke data, for example. They exist for a range of things, but primarily to give you a way to show bespoke content, like recipes, and linking them together in a specific way, dietary requirement for example. Storing anything that doesn’t fit into a custom post type and taxonomy doesn’t make sense, so don’t do it.