Symphony.

Symphony's better. No, I'm not here to start another crazy internet flame-war; "Symphony's Better" is a song by Aram David and you can hear it in this episode of Symcast.

In this episode, Alistair and I discuss Symphony 3's core, specifically concerns and suggestions Huib Keemink have made to the Symphony team (see below, under "Shownotes"). We also discussed a symphony hot topic: how to offer support for other database vendors through abstraction.

I'm not going to lie, this episode is full of technical sound bites exchanged between Alistair and a twice-fold digitised version of yours truly, which is barely strung together into something comprehensible. In fact, I wasn't even aware that the discussion I had with Alistair was going to be part of the Symcast recording until we were half way through our conversation. Even so, please don't be discouraged as both versions of Aram's song alone are well worth listening to.

Here's 30 minutes worth of Symphony talk: Symcast episode 2 (29.7MB).

Shownotes -- Huib's View on Symphony 3

Correct inheritance of abstract class definitions

As posted on the forum, the current extension class design is not really optimal. An extension extending the base extension class gains a few properties/functions (author, install() to name a few), but other functions still require a handle (enable, disable, status). Ideally, the extension can handle beeing enabled/disabled itself. This means that the current extension class is to be split in two, an extension loader class, and an extension base class containing only the functions needed to create a new extension.

This way, getting all active extensions can be done much more elegant, and less error prone.

In this case, the extension loader class can focus on including the right extensions at the right time (no datasource extensions have to be loaded if a section is edited), and on processing the delegates.

Make use of a strict naming scheme

Also posted on the forum, in my eyes forcing filenames in a specif format makes symphony less error-prone (and easier to build). Consider the current v3 extension format: if I want to check if a class exists, I have to record the classname from the include, link that to the filename (handle) and store it. Then I can compare the classname with the filename later, and see if it exists. If the filenames are strict, this is no longer needed, as the filename already contains the recipe for finding the classname.

Secondly, if two extensions include the same class (because less-specific names will follow if people can choose freely!), php will start throwing errors. If the classname is linked to its dirname, the end-user will notice right away if two extensions have the same name, because the OS will object. Also, having a strict naming scheme allows you to use the autoloading of classes. In my eyes, this saves a lot of headaches.

Using __autoload to include class files

Right now, quite a few different algorithms are used thoughout symphony to include files. (extensions, fields, datasources, events, etc). If the file structure is bound to rules, all of those can be replaces with a single __autoload function.

A huge benefit of this approach is that all of the including happens in a single function, so errors/bugs are easy to spot. Also, the chance of an "old" include method producing oddities is reduced.

Use an object for pretty much everything, and use type hinting to guarantee function input

This is a hard one to explain, but let me give an example: filenames on windows and linux are not handled the same. As a consequence, when testing on linux, some regex'es always work. If windows turns out to use a different format, all those regexes have to be fixed in order to keep the code working as intended. If however, the url was a url object beeing passed around, the return value of that object is the only things that needs to be rewritten.

Ofcourse, this is a very big step, and I understand it's quite impossible to build it into symphony at this stage. However, I do feel this could make symphony a whole let more stable in the future.

Besides passing objects around, symphony should perform more checks on the input of every function. Right now, a lot of assumptions are made on the content of the input of each function, while in my eyes, every function should still work as intended with every input possible. (again making symphony a lot more stable).

Only use objects if the situations requires an object. Use a function otherwise

Maybe this is only done in the URLWriter class, I'm not sure. However, the urlwriter should not be a class, but a function instead. Only use objects if the situation asks for something to be passed around, with properties and methods intact. (The url itself would be a better candidate, as a url could be passed around, has properties (host, page, arguments) and methods (it could be made relative, absolute, local, etc.))

Return values of iterators are not consistent

Some iterators return the object they iterate over, others return paths. (extensionIterator vs fieldIterator). Makes it very hard to write code without looking at the sourcecode of the iterators.