Download The Good Suite

This is the place where you can find the releases of The Good suite. The versioning system used follows Semantic Versioning. Since we are at the moment below version 1.0.0, this means that the public API is not yet stable and anything can still change. Since the APIs are so unstable and working with it is stilll quite verbose (you'll need a whole lot of boilerplate code, for example), the use of The Good Suite can't be recommended yet.

Version 0.5.0

The Good Suite v0.5 can be downloaded or visited on GitHub. More importantly, though, it can added as a composer dependency based on the GitHub repository, like this:

    {
        "repositories": [{
                "type": "vcs",
                "url": "https://github.com/TheGoodSuite/GoodSuite"
        }],
        "require": {
                "good/goodsuite": "0.5.0"
        }
    }
    

This is a leap forward, but it is one that has taken a lot of time to get to this point. Of course I've got a changelog, but I'll briefly talk about some of the highlights as well. Only some of them, though, because there are too many of them to talk about all of the highlights.

Collections in datatypes

    datatype AType {
        int intProperty;
        int[] collectionProperty;
    }
    

That's how easy it is. And having one-to-many relationships was always necessary so in the past I had to handle them in a relational-like fashion. This is just a lot better. It'll save a lot of time while also being quite flexible.

Condition system overhaul

The old system:

    $a = new MyType();
    $a->prop = 5;
    $geaterThan = new GreaterThan($a);

    $b = new MyType();
    $b->prop = 10;
    $lessThan = new LessThan($b);

    $between = new AndCondition($greaterThan, $lessThan);
    

The new system:

    $between = MyType::condition();
    $between->prop = new AndCondition(new GreaterThan(5), new LessThan(10));
    

(note: you can still use AndCondition similar to the old way, there was just no need here)

It's hard for me to write much about this, but I do believe the code samples show the differences pretty well. I'll just say that anyone who moved from the old to the new system (aka me) has found great improvements and looking back quickly starts to hurt a bit. And anyone who never touches the old API just gets to work with a very smooth API instead.

Changelog

• Datatypes can have members that are collections
• The Condition system has a completely different (and much smoother) API
• TheGoodSuite can be installed using Composer
• GoodService can JIT-Compile datatypes for you
• By providing a Page object, you can paginate fetchAll queries
• Datatypes can have members that are booleans
• Alongside MySQL, SQLite is now also supported


• Storables can easily be converted to arrays (which can be converted json using built-in php functionality)
• Fetching all storables of a type is now officially supported
• Storables and Collections can be resolved in-place
• You can test a storable against a Condition without involving the database
• toArray skips unresolved properties


• DateTime fields in datatypes compile to DateTimeImmutable instead of DateTime
• Manners is smarter about inferring which objects need to be inserted
• For ease of use, you can leave out the Resolver argument when fetching storables from storage
• Float fields also accept integer values
• var_dump works well on storables and collections
• The way nulls in conditions are translated to SQL was tweaked
• Resolver functions can be chained


• Column names are escaped properly
• The way to run test is now largely codified in a config file
• The tests run under a recent phpunit version
• Datetimes are properly converted to UTC before being saved in a storage
• Non-equality comparisons (<, >, <=, >=) to NULL throw an error
• Providing a condition that targets the wrong type throws an error
• Objects fetched from the database always have their properties set to the correct type
• Redefining a datatype raises an error

Version 0.4.0

The Good Suite v0.4 can be downloaded or visited on GitHub. There is still no documentation (which is planned for 0.5) and it still isn't easy to use.

API stability

The APIs that make up The Good Suite seem to finally be more or less stable. The datatype files, which were the one major issue in the previous release have had a major overhaul and no more changes are planned to it at the moment. This means that no backwards incompatible changes are planned at all. However, this is still a 0.x version and if the need arises, anything - including public APIs - can be changed.

Changelog

• A datatype defintion in a datatype file is no defined using datatype { }. This has several consequences. The first is that the name of the datatype is now contained in the datatype file, instead of living only in the code that initiates the compilation. This removes some of the "magic" that was happening and moves the datatype name to a much better place. A second consequences is that because the datatype is now delimited by braces, more than one datatype can be in a single file. This is generally not best practice, but it does remove arbitrary limitations by the system and gives the options to the user, which is where I believe they should lie. This syntax is inspired by a C-like programming languages and is what reduced some of the reliance on whitespace and what inspired the next change.
• A member definition that is in a datatype file is now ended by a semicolon instead of the end of a line. This way, the datatype format became even more C-like and largely whitespace independent.
• A primitive datatype can now be followed by one or more type modifiers between brackets. These type modifiers can either have no value or a numeric value. These serve to bridge the gap between the ideal datatype and the hardware restrictions the real world imposes. By making this explicit, we can check for it earlier rather than later and let the user configure which limits he or she wants to impose.
• There now is a proper API for dealing with ids, such as using them in conditions or fetching the object from it.
• Said ids can now also be accessed as a property, allowing proper access to them from a GoodLooking template, amongst things.
• When setting a primitive type property on a generated class, it will now be checked whether the value you set it to is of the correct value.
• Additionally, any limitations set by the type modifiers (or their defaults) are now also checked when updating these properties.
• The Good Looking sample has been moved out of The Good Suite and into The Good Samples.
• PHP tags are no longer allowed as a means to obscure the contents of your datatype files. This was never a good method and has now been removed to encourage better means to hide the fiels from prying eyes.
• The Storable interface was split into two: one that lists the requirements for being stored and another that lists the functions that ModifierStorable adds to your generated classes.
• A few tests on older functionality were improved or added.
• Something that was planned but not added is the addition of default values to the datatype files. Instead, this was considered to be behavior and thus removed from the planning as "won'tfix" all together.

Version 0.3.0

The third (pre-)release version of this software can be found as a download on this site and as a tag on GitHub. As with the previous versions, it comes with a big red warning label instead of documentation (as there is none of the latter yet) and for the version from the site, it is assumed you can handle a lzma-compressed .7z (after all, otherwise tyiou shouldn't be using this unstable software). Everything that's not in the archive can be found on Github.

API stability

The situation in API stability is more or less the same as with version 0.2: the type definition files are the only ones still completely in the dark. Most of this version's changes were to Good Looking and its API, but they were all additions. The Good Service generated classes actually took a step forward, as they are now backwards compatible with v0.2 and v0.1. There is a new API: the FunctionHandler API, which allows you to register functions to Good Looking. However, it was designed with an eye to the future, so it's presumed to be more or less stable. One big change that is still ahead of us is the caching for Good Looking and it might cause some backwards incompatibilities, but I do not see which yet, so it's hard to predict what the exact effects will be

Changelog

• In GoodService generated classes, public fields are accessible through properties and getters/setters. Protected fields are only accessible through getters and setters and have protected visibility again.
• Good Looking now supports variable assignment. It considers three kinds of variables: the template variables, which are registered outside the template but available inside it, the automatic variables, which are declared in a forrange or foreach loop and get their values changed automatically and the user variables, which are created through variable asignment of a variable that didn't exist yet. Only the last of the three sorts can be written to through variable assignment. Automatic variables can be reused, but only after the loop in which thety have a value.
• At the end of a forrange loop, the counter is no longer set to the number of items in the range. The idea was interesting, but not worth creating confusion and incompatibilities over.
• Good Looking has support for functions. By implementing the \Good\Looking\FunctionHandler interface you can specify your own functions for use in the templating language.
• A FunctionHandler handling noEscape is provided. The function gives you a way to print data which should not be escaped, which was not possible before at all.
• A FunctionHandler handling include is provided. 'Nuff Said.
• Array literals are supported in GoodLooking now through the use of "[" and "]". This probably be used for many other things as well, but it nicely allows for refactoring menus when the "current page" is not the same each time the menu is included.
• A handful of minor bugs was squashed

Version 0.2.0

Though this is the second release of the software, it's still not anywhere near a stable version. For those that want to use it anyway, it can be downloaded from this site or found as a tag on GitHub. It should be noted that there is no documentation, making it really hard to work with this. As with the previous version, some additional details have been left out from our download and it's a .7z. Everything else can be found on GitHub.

API stability

Since version 0.1, stability of APIs has increased considerably. The biggest winner is probably the Good Looking templating language. It has had a large overhaul and is now rather stable. Though some major additions to it are still planned, none of the planned additions are backwards incompatible.

The other major change is in the Good Service generated classes. These should also be mostly stable now, which finally makes them sort of usable. Interestingly, plans for the future include a change that makes them compatible with v0.1 and v0.2 (which are not compatible with one another).

The only completely unstable API left is that of the type defintion files. They still have a number of changes planned and while most of them probably won't be backwards incompatible, the name of a type is currently still specirfied in the calling code only, and the plan is to move this into the type definition files, which is not backwards compatible.

Changelog

• Classes that are generated by Good Service now use property syntax rather than getters and setters
• Collections of user objects returned by Good Manners are now Traversable, meaning you can use foreach to get their contents
• In the Good Looking templating language, "->" can now be used to access properties
• With the classes made by Good Service now directly usable from the Good Looking templating language, the layer that was temporarily between the two (LookingWithManners) has been removed.
• Good Manners can now use child classes of the classes generated by Good Service without resorting to name-based "hacks", providing a three-tiered system: without user intervention the generated classes are used, for simple cases child classes can simply be registered and when there are constructor arguments or other reasons for a more powerful system, the entire factory that constructs the objects can be replaced by one made by the user.
• The Good Looking templating language lost the "=" operator (which was equivalent to "==") and gained "===", "!==" and "%" (modulo)
• Variables are now referenced using the dollar sign as they are in PHP
• Foreach syntax went from "foreach (bla in blas)" to "foreach (blas as bla)", moving the language ever closer to PHP.
• Control structures have a colon at the end now, making sure they are the same as the PHP alternate control structure syntax, rather than being incompatible due to the lack of braces
• Semicolons are no longer necessary after control structres (but allowed, because empty statements are allowed as well) since they no longer made sense with the colons in place.
• Whitespace between "end" and "if" (and other control structures) is no longer allowed
• Control structures can now be capatilized in any way the user likes
• "for" was changed to "forrange" because it is not the same as PHP for
• In a forrange, one can now use "as" to get the counter variable a name
• The elseif control structure was added to the language
• Floating point numbers are now a part of this language
• Integers can't start with a zero, because that would mean something compeletely different in PHP. Here, we assume this is never what you wanted.

Version 0.1.0

This is the very first release of The Good Suite. It can be downloaded here or found as a tag on github. The release version is rather simple, using a .7z format (lzma compression). It was decided that if you aren't able to handle this file format, you're probably better off not using such an unstable API anyway and should wait for a better release instead. The release from this site also does not include empty modules, description files for the modules, extra materials such as UML sketches and the test suite. All of those can be found at github instead.

Unfortunately, there is no documentation or even a description of the public parts of the API yet. As such, such information can only be extracted from the tests, which can be found on github.

API stability

The most stable of our APIs is probably \Good\Memory API. However, that merely means that I expect no backwards incompatible changes, over there, I do expect a number of additions to the API to make it easier to work with. Unfortunately, you can't use this somehwat stable API without using the \Good\Service API of created objects, and that one's going to have a major backwards incompatible change in the near future: it's going from getter/setter functions to using properties.

There are two parts of the API that aren't actually part of the PHP API, but are part of the public interface of the library. The first of those is the language used in the datatype files This languge has a number of changes up ahead. Most of them are probably going to be backwards compatible, but there is one change that isn't. Namely, the name of the datatyoe, which is currently done outside the type system itself and in the PHP code, will be moved into the datatype files to keep them related things closer together.

The other "special" part of the API is the templating language, which has a major overhaul planned and is probably the part furthest from anything resembling stability. The idea is to bring this language closer to PHP, so the user won't really have to learn a new language. This will mean that many details will change, perhaps in a seemingly trivial manner.

Changelog

This being the first version to be released, there isn't a changelog.