challenges.yml

# Extending
extending_inheritfunctionalitycoding:
    question: |
        Your team has been working hard building the `DeathStar` class, only
        to find out that the Rebels have just destroyed it! Time to rebuild!
        
        Long live the Empire!
    question_steps:
        - |
          Create a new class called `DeathStarII` in the `DeathStarII.php` file
          and make it inherit all of the functionality from the original `DeathStar`.
        - In `index.php`, instantiate a new `DeathStarII` object and set it to a `$deathStar` variable.
        
    step: extending-inherit-functionality
    files:
        index.php: ~
        DeathStarII.php: ~
        DeathStar.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_variable:
            type: php
            assertTrue: variable_exists('deathStar')
            failure: Make sure the `$deathStar` variable is exist
        assert_instance_of_1:
            type: php
            assertTrue: get_class(variable('deathStar')) === 'DeathStarII'
            failure: The `$deathStar` variable exists, but is not set to a `DeathStarII` object.
        assert_instance_of_2:
            type: php
            assertTrue: is_subclass_of(variable('deathStar'), '\DeathStar')
            failure: The `DeathStarII` class is not extending `DeathStar` one.

extending_callnonexistentmethodmc:
    question: |
        Look at these two classes:

        ```php
        class Ship
        {
            public function getName()
            {
                return 'Starfighter';
            }
        }
        ```

        ```php
        class JediShip extends Ship
        {
            public function getFavoriteJedi()
            {
                return 'Yoda';
            }
        }
        ```

        Suppose we instantiate both objects:

        ```php
        $ship = new Ship();
        $jediShip = new JediShip();
        ```

        Which of the following lines will cause an error?
    explanation: |
        The `Ship` object does *not* have a `getFavoriteJedi()` method
        on it - only `JediShip` has this. But, since `JediShip extends Ship`,
        the `JediShip` *does* have a `getName()` method: it inherits it from
        `Ship`.
    features:
        multiple_choice:
            choices:
                a: |
                    ```php
                    echo $ship->getName();
                    ```
                b: |
                    ```php
                    echo $ship->getFavoriteJedi();
                    ```
                c: |
                    ```php
                    echo $jediShip->getName();
                    ```
                d: Both (B) and (C) will cause an error
            correct: b

# Override
override_overrideinheritmethodcoding:
    question: |
        Well, we learned some hard lessons after the destruction of the original `DeathStar`,
        and we don't want to repeat them!
    question_steps:
        - Override the `getWeakness()` method in `DeathStarII` and make it return `null`. Phew, problem solved!
    step: override-override-inherited-method
    files:
        DeathStarII.php: ~
        index.php:
            read_only: true
        DeathStar.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_method:
            type: php
            assertTrue: variable('new').getWeakness() === null
            failure: The `getWeakness()` method of `DeathStarII` class does not return `null`.

override_calloverriddenmethodmc:
    question: |
        Look at the following classes:

        ```php
        class Ship
        {
            public function printType()
            {
                echo 'Empire Ship';

                $this->printMotto();
            }

            public function printMotto()
            {
                echo 'I like to fly!';
            }
        }
        ```

        ```php
        class RebelShip extends Ship
        {
            public function printType()
            {
                echo 'Rebel Ship';
            }
        }
        ```

        What is the result of the following code:

        ```php
        $ship = new Ship();
        $rebelShip = new RebelShip();
        $ship->printType();
        $rebelShip->printType();
        ```
    explanation: |
        For `Ship`, `printType()` prints "Empire Ship" and then also
        calls `printMotto()`. But for `RebelShip`, `printType()` only
        prints "Rebel Ship". *Nothing* calls the `printMotto()`
        function in this case.
    features:
        multiple_choice:
            choices:
                a: Empire ShipRebel Ship
                b: Empire ShipI like to fly!Rebel Ship
                c: Empire ShipI like to fly!Rebel ShipI like to fly!
                d: RebelShipRebelShip
            correct: b

# ProtectedVisibility
protectedvisibility_getinheritedpropertycoding:
    question: |
        The construction of the `DeathStarII` continues, but we need access
        to the `planetarySuperLaserRange` property from the original, because
        we're going to make it fire twice as far!
    question_steps:
        - Fix the `DeathStar` class so that the new `getSpecs()` method works
    step: protected-visibility-get-inherited-property
    files:
        DeathStar.php: ~
        DeathStarII.php:
            read_only: true
        index.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_property:
            type: php
            assertTrue: reflection_class('\DeathStar').hasProperty('planetarySuperLaserRange')
            failure: The `planetarySuperLaserRange` property does not exist in the `DeathStar` class.
        check_property_visibility:
            type: php
            assertTrue: reflection_class('\DeathStar').getProperty('planetarySuperLaserRange').isProtected()
            failure: The `planetarySuperLaserRange` property should have protected visibility.

protectedvisibility_propertyvisibilitymc:
    question: |
        Check out the following code:

        ```php
        // Ship.php

        class Ship
        {
            public $name;

            protected $weaponPower;

            private $defense;

            public function getDefense()
            {
                return $this->defense;
            }
        }
        ```

        ```php
        // JediShip.php

        class JediShip extends Ship
        {
            public function getWeaponPower()
            {
                return $this->weaponPower;
            }
        }
        ```

        ```php
        // index.php

        $jediShip = new JediShip();
        $jediShip->name;
        $jediShip->weaponPower;
        ```

        Which of the above code will give us an error?
    explanation: |
        Since the `$defense` property is `private`, we can only access it from
        within the `Ship` class. But that's exactly what we're doing in (B),
        so that's fine.

        The `$weaponPower` property is `protected`. That means we can access it
        only from inside `Ship`, `JediShip` or any other sub-classes. That's why
        (C) is valid. But in (A), we're accessing `weaponPower` from `index.php`.
        Accessing a property or method from outside of the class is only allowed
        if it is public. This is a bad code.
    features:
        multiple_choice:
            choices:
                a: '`$jediShip->weaponPower` in `index.php`'
                b: '`return $this->defense` in `Ship.php`'
                c: '`return $this->weaponPower` in `JediShip.php`'
                d: None of the above is bad code - we're awesome!
            correct: a

# Parent
parent_callparentmethodcoding:
    question: |
        It took too long to travel to planets to destroy them
        in the first DeathStar, so Darth wants the laser range
        on the new DeathStar to be *twice* as far! Brilliant!
    question_steps:
        - |
          Override the `getLaserRange()` method in `DeathStarII` to make
          this happen. (But don't repeat the `2000000` value!)
        - Call the parent function and then multiply that value by 2!
    step: parent-call-parent-method
    files:
        DeathStarII.php: ~
        DeathStar.php:
            read_only: true
        index.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_method:
            type: php
            assertTrue: method_exists(variable('deathStar'), 'getLaserRange')
            failure: The `getLaserRange()` method does not exist for the `DeathStarII` class - did you create it?
        assert_method:
            type: php
            assertTrue: 4000000 === variable('deathStar').getLaserRange()
            failure: The `getLaserRange()` method in the `DeathStarII` class should return a doubled value of the parent method.

# AbstractShip
abstractship_extendabstractclasscoding:
    question: |
        We've just gotten word that the Rebels have *also*
        destroyed the `DeathStarII`. Wow, rotten luck. Anyways,
        it sounds like we'll be creating blue prints for many
        different types of DeathStars in the future, to keep
        the Rebels guessing.

        To make this easier... 
    question_steps:
        - Create an `AbstractDeathStar` class and move all of the shared code into it.
        - | 
          Update `DeathStar` and `DeathStarII` to extend this new class and make sure to get rid of anything in those classes
          that you've moved into the new parent class.
    step: abstract-ship-extend-abstract-class
    files:
        AbstractDeathStar.php: ~
        DeathStar.php: ~
        DeathStarII.php: ~
        index.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_class:
            type: php
            assertTrue: class_exists('\AbstractDeathStar')
            failure: The `AbstractDeathStar` class does not exist! Did you create it?
        check_methods:
            type: php
            assertTrue: reflection_class('\AbstractDeathStar').hasMethod('setWeaponPower') and reflection_class('\AbstractDeathStar').hasMethod('getWeaponPower') and reflection_class('\AbstractDeathStar').hasMethod('makeFiringNoise')
            failure: The `AbstractDeathStar` class should have `getWeaponPower()`, `setWeaponPower()`, and `makeFiringNoise()` methods.
        check_method:
            type: php
            assertFalse: reflection_class('\AbstractDeathStar').hasMethod('setCrewSize')
            failure: The `AbstractDeathStar` class should not have a `setCrewSize()` method! The `DeathStarII` just has a hardcoded crew size, so does not need this setter. Move it to `Deathstar`.
        assert_subclass_of:
            type: php
            assertTrue: reflection_class('\DeathStar').isSubclassOf('\AbstractDeathStar') and reflection_class('\DeathStarII').isSubclassOf('\AbstractDeathStar')
            failure: The both `DeathStar` and `DeathStarII` classes should extend `AbstractDeathStar` one.
        check_methods_removed:
            type: php
            assertFalse: |
                false
                or inputContains('DeathStar.php', 'getWeaponPower')
                or inputContains('DeathStar.php', 'setWeaponPower')
                or inputContains('DeathStar.php', 'makeFiringNoise')
            failure: The `DeathStar` class should not have `getWeaponPower()`, `setWeaponPower()`, `makeFiringNoise()` methods.
        check_property_removed:
            type: php
            assertFalse: inputContains('DeathStar.php', 'private $weaponPower')
            failure: The `DeathStar` class does not need `$weaponPower` property anymore.
abstractship_inheritanceoverheadmc:
    question: |
        A co-worker created a few classes and has asked for
        your advice about organizing them:

        ```php
        class Ship
        {
            private $name;

            public function getName()
            {
                return $this->name;
            }

            public function setName($name)
            {
                $this->name = $name;
            }

            // other stuff...
        }
        ```

        ```php
        class Person
        {
            private $name;

            public function getName()
            {
                return $this->name;
            }

            public function setName($name)
            {
                $this->name = $name;
            }

            // other stuff...
        }
        ```

        Your teammate is wondering if this can be organized better.
        Which if the following is the best advice?
    explanation: |
        Even though both classes share some code, a `Ship`
        and a `Person` fundamentally aren't the same thing,
        and probably don't have any other overlapping code.
        So, you *could* create an `AbstractNamedItem`, but
        that's a bit awkward. And remember, you can only
        extend *one* class, so make sure your parent class
        makes sense.

        In this case, the best action is to do nothing: leave
        these two blueprints totally independent. In a future
        episode, we'll talk about traits: a cool way to help
        remove duplication without inheritance.
    features:
        multiple_choice:
            choices:
                a: |
                    Create a new `AbstractNamedItem` class that has the
                    `name` property and the `getName()` and `setName()`
                    methods. Then, make `Person` and `Ship` extend this
                    class.
                b: |
                    Make `Ship` extend `Person`, and remove all the
                    duplicated code in `Person`.
                c: |
                    Leave things exactly like they are now.
            correct: c

# AddingAbstract
addingabstract_functiontypehintwithclassnamemc:
    question: |
        Check out these classes that the intern created,
        which all have confusing names:

        ```php
        abstract class OtherClass extends GreatClass
        {
        }
        ```

        ```php
        abstract class SomeClass extends OtherClass
        {
        }
        ```

        ```php
        class GreatClass
        {
        }
        ```

        ```php
        class MyClass extends OtherClass
        {
        }
        ```

        ```php
        class Puppy extends SomeClass
        {
        }
        ```

        ```php
        function doSomething(OtherClass $thing)
        {
            // ...
        }
        ```

        Based on the type-hint, objects of which classes could be passed
        to the `doSomething()` function?
    explanation: |
        Since the type-hint is `OtherClass`, any `OtherClass` object or sub-classes
        are accepted. The sub-classes are `MyClass` and `SomeClass` (directly)
        and also `Puppy` (though `SomeClass`). But we can instantiate objects
        *only* of `MyClass` and `Puppy` classes, because `OtherClass` and `SomeClass`
        are abstract!
    features:
        multiple_choice:
            choices:
                a: '`OtherClass` and `SomeClass`'
                b: '`OtherClass` and `MyClass`'
                c: '`MyClass` and `Puppy`'
                d: '`OtherClass` and `GreatClass`'
            correct: c

addingabstract_createabstractmethodcoding:
    question: |
        When Darth is browsing all the different `DeathStar` models, we want to print
        out a little description that describes each one. Inside of that description,
        we want to include the "laser range", but it's different based on the model.
    question_steps:
        - Create an abstract method called `getLaserRange()` in `AbstractDeathStar`.
        - Use that in `getDescription()` to set the `$range` variable.
        - Make sure the `DeathStar` class has range = 500.
        - Lastly, make sure the `DeathStarII` class has range = 900.
    step: adding-abstract-create-abstract-method
    files:
        AbstractDeathStar.php: ~
        DeathStarII.php: ~
        DeathStar.php: ~
        index.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        look_for_method:
            type: php
            assertTrue: reflection_class('\AbstractDeathStar').hasMethod('getLaserRange')
            failure: Method `getLaserRange()` does not exist in the `AbstractDeathStar` class. Did you create it?
        assert_abstract:
            type: php
            assertTrue: reflection_class('\AbstractDeathStar').getMethod('getLaserRange').isAbstract()
            failure: Method `getLaserRange()` declared in the `AbstractDeathStar` class should be abstract.
        assert_method_value:
            type: php
            assertTrue: 500 == variable('deathStar').getLaserRange() and 900 == variable('deathStar2').getLaserRange()
            failure: Method `getLaserRange()` should return `500` for the `DeathStar` class and `900` for the `DeathStarII`.
        assert_method_call:
            type: php
            assertTrue: inputContains('AbstractDeathStar.php', '->getLaserRange')
            failure: Did you call `getLaserRange()` method in the `AbstractDeathStar` class?
        check_output:
            type: http
            assertTrue: body() matches '/500/' and body() matches '/900/'
            failure: I don't see laser ranges in the output - did you print it?

# BrokenShip
brokenship_createdeathstariiicoding:
    question: |
        I feel like we're *always* designing new DeathStars. Well, no time to complain
        time to start the DeathStarIII!
    question_steps:
        - Create a new `DeathStarIII` class, make it extend `AbstractDeathStar`, and fill in any missing abstract methods. 
        - Lastly, print out the description in `index.php`.
    step: broken-ship-create-deathstartiii-class
    files:
        index.php: ~
        DeathStarIII.php: ~
        AbstractDeathStar.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_subclass_of:
            type: php
            assertTrue: reflection_class('\DeathStarIII').isSubclassOf('\AbstractDeathStar')
            failure: The `DeathStarIII` class should extend the `AbstractDeathStar` one.
        look_for_variable:
            type: php
            assertTrue: variable_exists('deathStar3')
            failure: I don't see the `$deathStar3` variable in `index.php` - did you create it?
        assert_instance_of:
            type: php
            assertTrue: get_class(variable('deathStar3')) === 'DeathStarIII'
            failure: The `$deathStar3` variable exists, but is not set to a `DeathStarIII` object.
        look_for_text:
            type: http
            assertTrue: css('h3').text() matches '/with a range of/'
            failure: Hmm, did you print the `DeathStarIII` description in the `h3` tag?
        assert_number:
            type: http
            assertTrue: css('h3').text() matches '/with a range of [0-9]+/'
            failure: The `getLaserRange()` method on `DeathStarIII` class must returns a number.

# PdoShipStorage
pdoshipstorage_decomposestringtransformercoding:
    question: |
        Tired from working on the DeathStar, you challenged the intern (let's call her
        "Morgan") to create a class that can reverse a string and upper case every other letter.
        "Ha!" Morgan says, "This is simple!". To show off, Morgan creates the `StringTransformer`
        class and *even* makes it cache the results to be super-performant.

        But wait you say! Combining the string transformation *and* caching into the same
        class make `StringTransformer` responsible for two jobs. Help show Morgan the intern
        a better way.
    question_steps:
        - Creating a new `Cache` class with two methods `fetchFromCache($key)` and `saveToCache($key, $val)`. 
        - Then, pass this into `StringTransformer` and use it to cache, instead of using your own logic.
    step: pdo-ship-storage-decompose-string-transformer
    files:
        index.php: ~
        StringTransformer.php: ~
        Cache.php: ~
    features:
        editor: ~
        browser: ~
    grading:
        check_class:
            type: php
            assertTrue: class_exists('\Cache')
            failure: Class `Cache` does not exist. Did you create it?
        check_method_from_cache:
            type: php
            assertTrue: reflection_class('\Cache').hasMethod('fetchFromCache')
            failure: Method `fetchFromCache()` does not exist in the `Cache` class.
        check_method:
            type: php
            assertTrue: reflection_class('\Cache').hasMethod('saveToCache')
            failure: Method `saveToCache()` does not exist in the `Cache` class.
        check_variable:
            type: php
            assertTrue: variable_exists('transformer')
            failure: I don't see the `$transformer` variable in `index.php` anymore - did you delete it?
        assert_variable:
            type: php
            assertTrue: get_class(variable('transformer')) === 'StringTransformer'
            failure: Make sure you give the `StringTransformer` class a `__construct()`. It should have one argument - a `Cache` object.
        assert_method:
            type: php
            assertTrue: reflection_class('\StringTransformer').hasMethod('__construct')
            failure: Make sure you give the `StringTransformer` class a `__construct()`. It should have one argument - a `Cache` object.
        look_for_function:
            type: http
            assertFalse: body() matches '/file_get_contents/'
            failure: I still see `file_get_contents()` inside of `StringTransformer`. Make sure you've moved all of the caching logic into the Cache class.
        # @TODO Create a mocked Cache, pass it into
        # @TODO $transformer and assert that its cache methods are called

pdoshipstorage_stringtransformerdecompositionadvantagesmc:
    question: |
        In the previous challenge, you split the logic from `StringTransformer`
        into two different classes. What are the advantages of this?
    explanation: |
        All of these are advantages! Before, you might not even realize that
        the `StringTransformer` had caching logic, but now its very obvious:
        the caching logic is in a class called `Cache` and you can see that
        the `StringTransformer` requires a `Cache` object. You could also use
        the `Cache` class in other situations to cache other things. And you
        could even - with a little bit of work - create a new `Cache` class
        that caches via something like Redis, and pass *this* to `StringTransformer`
        to cache using a different method.
    features:
        multiple_choice:
            choices:
                a: Each class is smaller and so easier to understand
                b: The `Cache` class could be re-used to cache other things
                c: You could easily use the `StringTransformer`, but cache using a different mechanism, like *Redis*
                d: All of these are real advantages
            correct: d

# AbstractShipLoader
abstractshiploader_createabstractplanetcoding:
    question: |
        Annoyed that the DeathStars are being destroyed, the Empire has decided to transform into
        a video game company. Awesome, they'll never see it coming! Two different teammates have 
        already created two classes to model this: `SolidPlanet` and `GasPlanet`. They look and 
        work differently, but both have `getRadius()` and `getHexColor()` methods. You've built a 
        `PlanetRenderer` class with a `render()` method, but it's not quite working yet.
    question_steps:
        - Create an `AbstractPlanet` class and update any other code you need to make these planets render!
    step: abstract-ship-loader-create-abstract-planet
    files:
        AbstractPlanet.php: ~
        SolidPlanet.php: ~
        GasPlanet.php: ~
        PlanetRenderer.php: ~
        index.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_class:
            type: php
            assertTrue: class_exists('\AbstractPlanet')
            failure: Class `AbstractPlanet` does not exist! Did you create it?
        assert_class_abstract:
            type: php
            assertTrue: reflection_class('\AbstractPlanet').isAbstract()
            failure: Class `AbstractPlanet` should be declared as abstract.
        check_method_1:
            type: php
            assertTrue: reflection_class('\AbstractPlanet').hasMethod('getRadius')
            failure: Method `getRadius()` does not exist in the `AbstractPlanet` class.
        assert_method_1_abstract:
            type: php
            assertTrue: reflection_class('\AbstractPlanet').getMethod('getRadius').isAbstract()
            failure: Method `getRadius()` should be declared as abstract.
        check_method_2:
            type: php
            assertTrue: reflection_class('\AbstractPlanet').hasMethod('getHexColor')
            failure: Method `getHexColor()` does not exist in the `AbstractPlanet` class.
        assert_method_2_abstract:
            type: php
            assertTrue: reflection_class('\AbstractPlanet').getMethod('getHexColor').isAbstract()
            failure: Method `getHexColor()` should be declared as abstract.
        check_subclass_of_1:
            type: php
            assertTrue: reflection_class('\SolidPlanet').isSubclassOf('\AbstractPlanet')
            failure: Class `SolidPlanet` should inherit the `AbstractPlanet` one.
        check_subclass_of_2:
            type: php
            assertTrue: reflection_class('\GasPlanet').isSubclassOf('\AbstractPlanet')
            failure: Class `GasPlanet` should inherit the `AbstractPlanet` one.

# Interfaces
interfaces_implementplanetinterfacecoding:
    question: |
        After watching this last episode, you realize that `AbstractPlanet` should really
        be an interface. I've given you a head start by creating the `PlanetInterface`.
    question_steps:
        - Update all of your code to use it and get these planets rendering again!
    step: interfaces-implement-planetinterface
    files:
        SolidPlanet.php: ~
        GasPlanet.php: ~
        PlanetRenderer.php: ~
        PlanetInterface.php:
            read_only: true
        index.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_implementing_1:
            type: php
            assertTrue: reflection_class('\SolidPlanet').implementsInterface('\PlanetInterface')
            failure: Class `SolidPlanet` should implement the `PlanetInterface` interface.
        assert_implementing_2:
            type: php
            assertTrue: reflection_class('\GasPlanet').implementsInterface('\PlanetInterface')
            failure: Class `GasPlanet` should implement the `PlanetInterface` interface.

interfaces_interfacevsabstractclassmc:
    question: |
        You over-hear the intern Bob telling another teammate about the differences between
        abstract classes and interfaces. He's *mostly* right, but he got one detail wrong.
        Which of the following is *not* true:
    explanation: |
        `C` is the only answer that's incorrect: both interfaces and abstract classes can
        force you to implement methods in the classes that use them. So in many ways, they
        are the same.

        So why use one or the other? Well, a class can implement *many* interfaces, which
        makes interfaces more attractive, especially for re-usable code. But, an abstract
        class can contain *real* methods, which can help you reduce code duplication between
        classes. They're similar, but not the same.
    features:
        multiple_choice:
            choices:
                a: Classes can implement many interfaces, but only extend one class.
                b: Abstract classes can contain concrete methods, but interfaces can't.
                c: Interfaces force the user to implement certain methods, abstract classes do not.
                d: |
                    Even though Interfaces don't use the `abstract` keyword before methods,
                    those methods act just like abstract methods in an abstract class.
            correct: c

interfaces_implementweaponinterfacecoding:
    question: |
        Finally something fun! Now you're working on creating different weapons for the 
        spaceships in our game.
    question_steps:
        - | 
          Looking at the `WeaponInterface` create a new `LaserWeapon` class that implements
          this interface. You can return anything you want from the methods. Just don't let the
          freedom go to your head.
        - Use the class to print out the weapon's range, just to see that things are working.
    step: interfaces-implement-weaponinterface
    files:
        index.php: ~
        LaserWeapon.php: ~
        WeaponInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_class:
            type: php
            assertTrue: class_exists('\LaserWeapon')
            failure: Class `LaserWeapon` could not be found. Did you create it?
        check_implementing:
            type: php
            assertTrue: reflection_class('\LaserWeapon').implementsInterface('\WeaponInterface')
            failure: Class `LaserWeapon` should implement the `WeaponInterface` interface.
        look_for_method:
            type: php
            # TODO Wondering how can we get expressions from both http and php types togeather in one assertion?
            # I think we have a preblem here for now:
            #assertTrue: body() matches /get_variable('laserWeapon').getWeaponRange()/
            assertTrue: inputContains('index.php', 'getWeaponRange')
            failure: Seems you forgot to output the laser weapon range. Did you print the result of the `getWeaponRange()` method?

# Episode 4

# class-constants
classconstants_replacestringswithconstantscoding:
    question: |
        Our cool `GasPlanet` class is smart! We tell it what
        "main element" the planet is made out of (e.g. ammonia),
        and `getHexColor()` tells us the color of the planet.

        But, it's too easy to make a typo - e.g. `amonia` - when
        passing in the element.
    question_steps:
        - |
            Add 4 new constants to `GasPlanet` - one for each of
            the 4 materials. Give them descriptive names, like
            `MATERIAL_AMMONIA`.
        - |
            Ok! Replace the strings in your code with these
            constants.
    step: class-constants-replace-strings-with-constants
    files:
        index.php: ~
        GasPlanet.php: ~
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_constant_1:
            type: php
            assertTrue: reflection_class('\GasPlanet').hasConstant('MATERIAL_AMMONIA')
            failure: Did you add a `MATERIAL_AMMONIA` constant to the `GasPlanet` class?
        check_constant_2:
            type: php
            assertTrue: reflection_class('\GasPlanet').hasConstant('MATERIAL_HYDROGEN')
            failure: Did you add a `MATERIAL_HYDROGEN` constant to the `GasPlanet` class?
        check_constant_3:
            type: php
            assertTrue: reflection_class('\GasPlanet').hasConstant('MATERIAL_HELIUM')
            failure: Did you add a `MATERIAL_HELIUM` constant to the `GasPlanet` class?
        check_constant_4:
            type: php
            assertTrue: reflection_class('\GasPlanet').hasConstant('MATERIAL_METHANE')
            failure: Did you add a `MATERIAL_METHANE` constant to the `GasPlanet` class?
        check_constant_usage_1:
            type: php
            assertTrue: |
                true
                and inputContains('GasPlanet.php', '::MATERIAL_METHANE')
                and inputContains('GasPlanet.php', '::MATERIAL_HYDROGEN')
                and inputContains('GasPlanet.php', '::MATERIAL_HELIUM')
                and inputContains('GasPlanet.php', '::MATERIAL_METHANE')
            failure: Replace all hardcoded strings with the new `MATERIAL_*` constants in the `GasPlanet` class.
        check_constant_usage_2:
            type: php
            assertTrue: |
                true
                and inputContains('index.php', 'GasPlanet::MATERIAL_AMMONIA')
                and inputContains('index.php', 'GasPlanet::MATERIAL_METHANE')
            failure: Replace the hardcoded strings with the new `MATERIAL_AMMONIA` and `MATERIAL_METHANE` constants in the `index.php`.

classconstants_uppercaseconstantsmc:
    question: Why are constants always upper-case (e.g. `MATERIAL_AMMONIA`)?
    explanation: |
        The upper-casing of constants is just a standard, but standards
        are good to follow! A constant is distinguished from a property
        by their keyword and the use of a `$`: `const PIZZA` versus `private $pizza`.
    features:
        multiple_choice:
            choices:
                a: "It's just a standard: constants don't *need* to be upper-case"
                b: The upper-case characters distinguish them from normal properties
                c: Upper-case class constants are used so that they don't conflict with core PHP constants
                d: The upper-case characters help keep memory usage lower
            correct: a

classconstants_setconstantmc:
    question: |
        Suppose you want to change the value of a constant.
        Check out the following code:

        ```php
        class GasPlanet
        {
            const MATERIAL_AMMONIA = 'ammonia';
        }
        ```

        ```php
        <?php
        // ...

        GasPlanet::MATERIAL_AMMONIA = 'helium';
        ```

        Is this legal?
    explanation: |
        Constants can *never* be changed - that's the whole point! And
        they *must* be declared inside of the class with the `const` keyword.

        If you need a value that *changes*, then you don't need a constant,
        you need a *property*. And as you'll learn in a few minutes, properties
        can be static (like constants) or non-static (stay-tuned!).
    features:
        multiple_choice:
            choices:
                a: |
                    Yes, but it's not recommended. Constants are values that
                    are not *meant* to be modified.
                b: |
                    No, unless you removed the `const MATERIAL_AMMONIA = 'ammonia';`
                    from `GasPlanet`. Constants can only be set *once* either via
                    the `const` keyword, or by setting them from outside the class.
                c: Nope - changing constants is totally *not* allowed, ever.
                d: |
                    Yes, though it's recommended to change constants from inside
                    the class where they are declared (i.e. `GasPlanet`).
            correct: c

classconstants_hexcolorconstantsmc:
    question: |
        The intern has gone *crazy* with constants, by even making the
        hex strings into constants:

        ```php
        class GasPlanet implements PlanetInterface
        {
            // ...

            const COLOR_BROWN_ISH = '663300';
            const COLOR_BLUE_BRIGHT = '0066FF';
            const COLOR_GRAY_DARK = '464646';
            // ...

            public function getHexColor()
            {
                // a "fake" map of elements to colors
                switch ($this->mainElement) {
                    case GasPlanet::MATERIAL_AMMONIA:
                        return GasPlanet::COLOR_BROWN_ISH;
                    case GasPlanet::MATERIAL_METHANE:
                        return GasPlanet::COLOR_BLUE_BRIGHT;
                    default:
                        return GasPlanet::COLOR_GRAY_DARK;
                }
            }
        }
        ```

        Is this a good step forward?
    explanation: |
        Not *all* strings or numbers should be turned into constants.
        If you're thinking about making something a constant, ask yourself:

        * Are these strings used multiple times?
        * Are these strings used from *outside* of the class?
        * If someone makes a minor typo, will the result be drastically different?
        * Is it important for us to have a list of all of these possible values in one spot.

        In this case, the answer is no to *all* of these questions. For
        example, if we typo `ammonia` as `amonia`, the planet would have
        a drastically different color. But if we typo `663300` as `663301`,
        that won't make much difference, because the hex values are not
        being used as *exact keys* to decide how the code behaves.
    features:
        multiple_choice:
            choices:
                a: |
                    Not really. These hex colors aren't used outside of this
                    class ever (or even multiple times *inside* of this class),
                    so there's no advantage to making these constants.
                b: "Absolutely: it's important to make all static strings into constants."
                c: "No: the hex colors shouldn't be constants, in case we need to change them later."
            correct: a

# static-vs-non-static-and-self
staticvsnonstaticandself_staticpropertymc:
    question: |
        The intern is *loving* the idea of static properties, but I feel
        like he's a little confused. But, he's got a good spirit! Let's
        check out his code and offer him some advice:

        ```php
        class SolidPlanet
        {
            private $radius;

            private static $hexColor;

            private $hasBeenVisitedByAliens;

            private $numberOfHabitablePlanetsInUniverse;
        }
        ```

        Which of the following are true:
    explanation: |
        When determining static or non-static, ask yourself this question:

        > Does *each* individual planet have its own value for this
        > property? Or is there just one value for *all* planets?

        Looking at each property, here's how it looks:

        * `radius`: Each planet has a different radius: *not static*
        * `hexColor`: Each planet also has its own color: *non static*
        * `hasBeenVisitedByAliens`: Some planets may have been visited by aliens
          and others not: *non static*
        * `$numberOfHabitablePlanetsInUniverse`: This is a global number,
          it applies to *all* planets: it's not a property of just one
          planet: *static*

        When in doubt, use non-static!
    features:
        multiple_choice:
            choices:
                a: The `$hexColor` property should *not* be static
                b: The `$radius` property should be static
                c: The `$numberOfHabitablePlanetsInUniverse` should be static
                d: Both (A) and (C) are true!
                e: Both (B) and (C) are true!
            correct: d

staticvsnonstaticandself_useselfkeywordcoding:
    question: |
        We're doing too much work in `GasPlanet` by using the *whole* class name
        (`GasPlanet`) to reference the constants!
    question_steps:
        - 'Update the `GasPlanet::getHexColor()` method to use `self` to reference the constants.'
    step: static-vs-non-static-and-self-replace-class-name-with-self
    files:
        GasPlanet.php: ~
        index.php:
            read_only: true
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_constant_usage:
            type: php
            assertTrue: |
                true
                and inputContains('GasPlanet.php', 'self::MATERIAL_METHANE')
                and inputContains('GasPlanet.php', 'self::MATERIAL_HYDROGEN')
                and inputContains('GasPlanet.php', 'self::MATERIAL_HELIUM')
                and inputContains('GasPlanet.php', 'self::MATERIAL_METHANE')
            failure: Replace all `GasPlanet::MATERIAL_*` code with `self::MATERIAL_*` in the `GasPlanet` class.

# static-methods
staticmethods_staticgetallelementscoding:
    question: |
        The gas planets are kind of pretty, so we want to render
        *all* of them for the user to enjoy. Simple! By creating
        one `GasPlanet` object in `index.php` for each possible element, we've
        done it!

        But, you know the problem: if we add *more* elements to
        `GasPlanet`, we'll need to remember to come here and create
        another object. Lame!
    question_steps:
        - |
            Create a new *static* method in `GasPlanet` called `getAllElements()`
            that returns the 4 possible gas planet elements.
        - |
            In `index.php`, call this new method and use a `foreach` to
            create and render the 4 different gas planets. Use any diameter you
            want for the planets.
    step: static-methods-get-all-elements
    files:
        index.php: ~
        GasPlanet.php: ~
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_for_method:
            type: php
            assertTrue: reflection_class('\GasPlanet').hasMethod('getAllElements')
            failure: Did you add the `getAllElements()` method to the `GasPlanet.php` class?
        assert_method_is_static:
            type: php
            assertTrue: reflection_class('\GasPlanet').getMethod('getAllElements').isStatic()
            failure: Did you make the `getAllElements()` method static?
        search_for_method_call:
            type: php
            assertTrue: inputContains('index.php', 'GasPlanet::getAllElements()')
            failure: Did you call and loop over the `GasPlanet::getAllElements()` method from inside `index.php`?
        search_for_foreach:
            type: php
            assertTrue: inputContains('index.php', 'foreach')
            failure: Did you iterate over all elements with a `foreach` loop in `index.php`?
        search_for_new_object:
            type: php
            assertTrue: inputContains('index.php', 'new GasPlanet')
            failure: Did you create a `new GasPlanet` object in the `foreach` loop?
        check_basic_output:
            type: http
            assertTrue: |
                body() matches "/border-radius/"
            failure: "I don't see any planets rendered! Did you remember to render them and echo the output?"

staticmethods_fixerrorscoding:
    question: |
        You take *one* day for a holiday, and the intern experimented
        in the code and broke things! Now that you're back, well-rested
        and with a nice tan, see if you can **fix the error**.
    question_steps:
        - Render the page to see what the error is
        - Find the bug and squash it!
    explanation: |
        When deciding between making a method static or non-static,
        one easy question to ask is:

        > Does this method need to use the `$this` variable?

        If it *does*, then it should *not* be static. Simple!
    step: static-methods-create-randomlycoloredplanet-class
    files:
        RandomlyColoredPlanet.php: ~
        index.php:
            read_only: true
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_method_is_not_static:
            type: php
            assertFalse: reflection_class('\RandomlyColoredPlanet').getMethod('getRandomColor').isStatic()
            failure: You should make the `getRandomColor()` method **not** static.
        check_method_call_with_this:
            type: php
            assertFalse: inputContains('RandomlyColoredPlanet.php', 'self::getRandomColor')
            failure: You can *technically* call the non-static `getRandomColor()` method with `self::`, but it's improper. Use `$this->` instead inside of the `getHexColor()` method.
        check_argument_name:
            type: php
            assertTrue: inputContains('RandomlyColoredPlanet.php', '__construct($color1, $color2)')
            failure: There's one more typo with the second argument name in the constructor. Did you see it?

staticmethods_staticvsnonstaticmc:
    question: |
        We're building a new class of planets that *always* have the
        same radius. We're in a heated (geeky) debate over whether or
        not to make a method static. Here are the two options:

        ```php
        // OPTION 1
        class StaticallySizedPlanet
        {
            public function getRadius()
            {
                return 250;
            }
        }
        ```

        ```php
        // OPTION 2
        class StaticallySizedPlanet
        {
            public static function getRadius()
            {
                return 250;
            }
        }
        ```

        Which would you recommend?
    explanation: |
        This one is tough :).

        Deciding whether or not to make a method static has *nothing*
        to do with whether or not that method will return a "static"
        (or constant value). And just because you *don't* need the
        `$this` keyword does *not* automatically mean that you should
        make something static (though the opposite *is* true: if you
        need `$this`, make it non-static).

        Instead, you need to ask yourself:

        > When I call this method, am I calling this method on one
        > individual "planet" object or on the StaticallySizedPlanet
        > class in general?

        In this case, both sound pretty reasonable: so both static
        and non-static are *good* answers. However, if you're ever
        not sure - or both options make sense - choose non-static.
        Put simply: this will give you more flexibility in the future.
    features:
        multiple_choice:
            choices:
                a: |
                    OPTION 1 (non-static): The "radius" of a planet is a
                    property that should really belong to each, individual planet.
                b: |
                    OPTION 1 (non-static): "getter" functions like this
                    (e.g. `getRadius()`, `getName()`, etc) should always be non-static.
                c: |
                    OPTION 2 (static): The method does not rely on the
                    `$this` variable, so we should make it static.
                d: |
                    OPTION 2 (static): The method always returns a static,
                    or constant value. This is precisely when you should use
                    a static method.
            correct: a

# namespaces-make-class-names-longer
namespacesmakeclassnameslonger_addnamespacecoding:
    question: |
        Since we *love* long class names, we're going to start giving
        our classes namespaces!

        (But seriously, I'll show you why namespaces are *actually* awesome soon).
    question_steps:
        - Give `RandomlyColoredPlanet` a namespace of `Model\Planet`
        - |
          **Without** using a `use` statement, update `index.php` so
          that everything still works.
    step: namespaces-make-class-names-longer-add-namespace
    files:
        index.php: ~
        RandomlyColoredPlanet.php: ~
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_namespace:
            type: php
            assertTrue: class_exists('Model\\Planet\\RandomlyColoredPlanet')
            failure: You should add the `Model\Planet` namespace to the `RandomlyColoredPlanet` class.
        check_fqcn_usage:
            type: php
            assertTrue: inputContains('index.php', 'Model\\Planet\\RandomlyColoredPlanet')
            failure: Did you use the fully qualified class name `Model\Planet\RandomlyColoredPlanet` in the `index.php`?
        search_for_use:
            type: php
            assertFalse: inputContains('index.php', 'use ')
            failure: "You shouldn't add a `use` statement to complete this challenge. It's legal, but try getting the code to work without it!"

namespacesmakeclassnameslonger_usenamespacecoding:
    question: |
        Even though we don't *need* to use `use` statements, we almost
        always do.
    question_steps:
        - Update `index.php` to use a `use` statement for the `RandomlyColoredPlanet` class.
    step: namespaces-make-class-names-longer-add-use-statement
    files:
        index.php: ~
        RandomlyColoredPlanet.php:
            read_only: true
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_for_use_with_slash:
            type: php
            assertFalse: inputContains('index.php', 'use \\Model\\Planet\\RandomlyColoredPlanet;')
            failure: You don't have to use a starting slash `\` when using a namespace. Let's remove it!
        search_for_use_without_slash:
            type: php
            assertTrue: inputContains('index.php', 'use Model\\Planet\\RandomlyColoredPlanet;')
            failure: 'You should add a `use` statement for the `RandomlyColoredPlanet` class namespace in `index.php`. You *could* also just reference the long class name when you use it, but `use` statements are much more common.'
        search_for_use:
            type: php
            assertTrue: inputContains('index.php', 'new RandomlyColoredPlanet')
            failure: You don't have to use the full namespace to reference the class after you add the `use` statement - just say `new RandomlyColoredPlanet()`.

namespacesmakeclassnameslonger_useonemorenamespacecoding:
    question: |
        Since you're feeling pretty comfortable with namespaces, you
        decide to delegate the rest of the work to the intern. Nice
        management move!

        But, when you get the code back, things aren't *quite* right.
    question_steps:
        - Load the page to see the error
        - Find the problem and fix it!
    step: namespaces-make-class-names-longer-add-namespace-to-the-planetrenderer
    files:
        index.php: ~
        RandomlyColoredPlanet.php:
            read_only: true
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_for_use_with_slash:
            type: php
            assertFalse: inputContains('index.php', 'use \\Service\\PlanetRenderer;')
            failure: You don't have to use a starting slash `\` when using a namespace. Let's remove it!
        search_for_use_without_slash:
            type: php
            assertTrue: inputContains('index.php', 'use Service\\PlanetRenderer;')
            failure: You should add a `use` statement for the `PlanetRenderer` class.
        search_for_use:
            type: php
            assertTrue: inputContains('index.php', 'new PlanetRenderer')
            failure: You don't have to use the full namespace to reference the class after you add the `use` statement - just say `new PlanetRenderer()`.

namespacesmakeclassnameslonger_namespaceusagemc:
    question: |
        Look at the following class:

        ```php
        namespace Model\Planet.

        class RandomlyColoredPlanet
        {
            // ...
        }
        ```

        Which of the following is *not* a valid way to reference
        this class from inside `index.php`:
    explanation: |
        Trick question! Well, sort of :).

        One of the most common errors with `use` statements is
        to forget that you need to include the namespace *and* the
        class name:

        ```php
        use Model\Planet; // wrong
        use Model\Planet\RandomlyColoredPlanet; // correct!

        new RandomlyColoredPlanet();
        ```

        This is because PHP sees `RandomlyColoredPlanet` and looks
        for a `use` statement that *ends* with this string.

        If you *do* forget the last part of the `use` statement
        (e.g. `use Model\Planet`), you can technically get your
        code to work by saying `new Planet\RandomlyColoredPlanet()`.
        This is pretty rare to see in the wild.
    features:
        multiple_choice:
            choices:
                a: |
                    ```php
                    new Model\Planet\RandomlyColoredPlanet();
                    ```
                b: |
                    ```php
                    use Model\Planet;

                    new RandomlyColoredPlanet();
                    ```
                c: |
                    ```php
                    use Model\Planet;

                    new Planet\RandomlyColoredPlanet();
                    ```
                d: All of these are correct!
            correct: b

# autoloading-awesomeness
autoloadingawesomeness_addautoloadercoding:
    question: |
        These `require` statements are *really* starting to cramp
        my style! Start simple:
    question_steps:
        - Remove the `require` statement for `RandomlyColoredPlanet.php`.
        - Add an autoloader function (`spl_autoload_register`) at the top of `index.php`.
        - Inside that function, if the class equals `Model\Planet\RandomlyColoredPlanet`, require that file.
        - Refresh to see everything working *without* the `require` statement!
    step: autoloading-awesomeness-add-simple-autoloader
    files:
        index.php: ~
        RandomlyColoredPlanet.php:
            read_only: true
        PlanetInterface.php:
            read_only: true
        PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_for_function:
            type: php
            assertTrue: inputContains('index.php', 'spl_autoload_register')
            failure: You should register your autoloader function by calling `spl_autoload_register`.
        search_for_if:
            type: php
            assertTrue: inputContains('index.php', 'if')
            failure: You should require the file only if the class name is equal to `Model\Planet\RandomlyColoredPlanet`.
        search_for_file:
            type: php
            assertTrue: inputContains('index.php', 'RandomlyColoredPlanet.php')
            failure: You should require the `RandomlyColoredPlanet.php` file inside of your autoloader function.

autoloadingawesomeness_betterperformancemc:
    question: |
        Ultimately - whether via a manual `require` statement written
        by you or via an autoloader function - *something* needs to
        require/include a file before we can use the class that lives
        inside of it.

        But, which option will give you better performance?
    explanation: |
        Not only are autoloaders going to make your life simpler, they're
        *faster* than manually writing require statements. Well, most of
        the time :).

        The big reason is that - with an autoload function - you only
        include a file *if* you actually need it during a request. If
        you never reference a class, then you never include its file
        and never incur the added overhead of loading this class into
        memory. Yay!

        But to make this a reality, the *logic* inside of your autoloaders
        needs to be fast! If your logic searches various files to look
        for a class each time the autoloader is called, that will be *way*
        slow!

        That's why the autoloader we built in the tutorial takes advantage
        of a class's namespace to quickly locate it!
    features:
        multiple_choice:
            choices:
                a: Autoloaders are *always* faster than manually having many require statements.
                b: |
                    Autoloaders are *usually* faster than having require
                    statements, because you don't need to include files that
                    you don't use.
                c: |
                    Manual require statements are *always* faster than autoloaders.
                    Yes, they're annoying to write, but there is a lot of extra
                    overhead for calling the autoload function over and over again.
                d: |
                    Manual require statements are *always* faster than an
                    autoloader function. By requiring all of the files in the
                    very beginning, your application can quickly reference any
                    class or function it needs.
            correct: b

# more-with-use-statements
morewithusestatements_usesmartautoloadercoding:
    question: |
        Time to remove *all* of the `require` statements! YES!

        We made the intern work late last night, and he got us off
        to a nice start: the classes now live in different directories
        *and* our `spl_autoload_register` function is smart!
    question_steps:
        - Remove all of the require statements
        - Give each class a proper namespace so that the autoload function can find them! Remember, the namespace should match the directory, but without the `src/` part!
        - Fix anything else needed in the code after giving the classes namespaces
    step: more-with-use-statements-use-smart-autoloader
    files:
        index.php: ~
        src/Model/Planet/PlanetInterface.php: ~
        src/Model/Planet/GasPlanet.php: ~
        src/Model/Planet/SolidPlanet.php: ~
        src/Model/Planet/RandomlyColoredPlanet.php: ~
        src/Service/PlanetRenderer.php: ~
    features:
        editor: ~
        browser: ~
    grading:
        search_for_require:
            type: php
            assertFalse: |
                false
                or inputContains('index.php', 'PlanetRenderer.php')
                or inputContains('index.php', 'GasPlanet.php')
                or inputContains('index.php', 'SolidPlanet.php')
                or inputContains('index.php', 'RandomlyColoredPlanet.php')
            failure: You should remove all of the `require` statements in `index.php` except the one in the `spl_autoload_register` function.
        assert_namespace:
            type: php
            assertTrue: |
                true
                and class_exists('\\Service\\PlanetRenderer')
                and class_exists('\\Model\\Planet\\GasPlanet')
                and class_exists('\\Model\\Planet\\SolidPlanet')
                and class_exists('\\Model\\Planet\\RandomlyColoredPlanet')
            failure: Make sure that *every* class has a namespace (and that the namespace matches the directory structure!)

morewithusestatements_fixnamespacecoding:
    question: |
        Ok, I *swear* this was all working a second ago. But, it looks
        like someone accidentally changed something and broke everything!
    question_steps:
        - Reload the page to see the error
        - Find the bug and squash it! The error is in `GasPlanet`.
    step: more-with-use-statements-fix-invalid-namespace
    files:
        src/Model/Planet/GasPlanet.php: ~
        index.php:
            read_only: true
        src/Model/Planet/SolidPlanet.php:
            read_only: true
        src/Model/Planet/RandomlyColoredPlanet.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_namespace:
            type: php
            assertTrue: class_exists('\\Model\\Planet\\GasPlanet')
            failure: The namespace inside `GasPlanet` *must* match its directory structure.

# namespaces-core-php-classes
namespacescorephpclasses_addplanetdaylengthcoding:
    question: |
        The length of a day on Earth is 24 hours, but other planets have
        *drastically* different day lengths! No problem! We've already
        added a new property to `SolidPlanet` - `dayLengthInHours` - to
        help control this.

        Now, we want to be able to print *when* one day from now will
        be for a specific planet.
    question_steps:
        - Add a new method to `SolidPlanet` called `getDateTimeOneDayFromNow()`.
        - |
            Inside, create a new `DateTime` object and add X hours to it,
            where X is the value of the `dayLengthInHours` property. You can
            use the commented-out `DateTime` code in `index.php` as a guide!
        - |
            In `index.php`, call the new `getDateTimeOneDayFromNow()` method
            and set it to a variable called `$tomorrow` so that it will be
            rendered in the `h3` tag.
    step: namespaces-core-php-classes-use-planet-day-length
    files:
        index.php: ~
        src/Model/Planet/SolidPlanet.php: ~
        src/Service/PlanetRenderer.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_for_method:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\SolidPlanet').hasMethod('getDateTimeOneDayFromNow')
            failure: You should add a `getDateTimeOneDayFromNow()` method to the `SolidPlanet` class.
        assert_datetime:
            type: php
            assertTrue: get_class(variable('planet').getDateTimeOneDayFromNow()) === 'DateTime'
            failure: You should return a `DateTime` object in the `getDateTimeOneDayFromNow()` method.
        search_for_method_usage:
            type: php
            assertTrue: inputContains('index.php', '->getDateTimeOneDayFromNow()')
            failure: Did you use the `getDateTimeOneDayFromNow()` method in `index.php`?

namespacescorephpclasses_datetimemc:
    question: |
        Which of the following pieces of code would **not** work:
    explanation: |
        The best code is probably (A): `new \DateTime()`. This
        will *always* work, whether you're in a file with a namespace
        or not.

        If you simply say `new DateTime()`, this only *might* work.
        If you're in a file whose namespace is `Foo`, then PHP thinks
        you're referring to a class called `Foo\DateTime` (wrong!).
        That's why adding the `\` in front is always best.

        The final answer - with the `use DateTime` - looks a little
        funky, but is also technically valid. A `use` statement always
        anchors from the *root* of the namespace. In other words, even
        though we type `use DateTime`, it means `use \DateTime`. So yes,
        you actually *can* use `use` statements with core PHP classes.
    features:
        multiple_choice:
            choices:
                a: |
                    ```php
                    namespace Foo;

                    new \DateTime();
                    ```
                b: |
                    ```php
                    // not in a namespaced file

                    new DateTime();
                    ```
                c: |
                    ```php
                    namespace Foo;

                    new DateTime();
                    ```
                d: |
                    ```php
                    namespace Foo;

                    use DateTime;

                    new DateTime();
                    ```
                e: These would all work!
            correct: c

# composer-autoloading
# not ready - requires a terminal in the challenge!
# composerautoloading_composerautoloadercoding:
#     question: |
#         Ok! Let's use Composer's autoloader instead of our, home-grown
#         code. Yay to less code!
#     question_steps:
#         - Delete our `spl_autoload_register()` function
#         - |
#           Give `composer.json` the proper `autoload` section so
#           that it knows to find our classes in the `src/` directory
#         - |
#           Run `composer install` so that it generates the
#           `vendor/autoload.php` file
#         - |
#           Require `vendor/autoload.php` from `index.php` and make
#           sure everything still works!
#     step: composer-autoloading-composer-autoloader
#     files:
#         index.php: ~
#         composer.json: ~
#         src/Model/Planet/SolidPlanet.php:
#             read_only: true
#         src/Service/PlanetRenderer.php:
#             read_only: true
#         src/Model/Planet/PlanetInterface.php:
#             read_only: true
#     features:
#         editor: ~
#         browser: ~
#     grading:
#         pending:
#             type: php
#             assertTrue: 1 == 0
#             failure: This can only be done when we have terminal ability
#         search_for_function:
#             type: php
#             assertFalse: inputContains('index.php', 'spl_autoload_register')
#             failure: You should remove your custom autoloader function.
#         search_for_require:
#             type: php
#             assertTrue: inputContains('index.php', 'vendor/autoload.php')
#             failure: You should require the Composer autoloader (`vendor/autoload.php`).
#         search_for_text:
#             type: php
#             assertTrue: inputContains('composer.json', '"autoload"') and inputContains('composer.json', '"src/"')
#             failure: Did you add an `autoload` section in `composer.json` that points to the `src/` directory of your project?

# boo - not ready yet :(
# composerautoloading_autoloadlegacycodecoding:
#     question: |
#         Oh no, we have a problem! Pretend that we're updating an old,
#         ugly, legacy application. This code contains a class called
#         `LegacyHelper`, but it doesn't have a namespace and doesn't
#         live in the `src/` directory. This means that the Composer
#         autoloader can't find it! And since we're trying to use it
#         from inside `PlanetRenderer`, our code is broke!
#
#         This *should* be easy to fix (just move the file and give the
#         class a namespace), but we *can't* modify the class: it's still
#         being used by an old legacy application that we can't touch.
#         Dang!
#
#         No problem - the Composer autoloader can still help us!
#     question_steps:
#         - |
#           If you have some classes that do *not* follow the nice
#           PSR-0 naming standard, Composer *can* still autoload these.
#           Google for "Composer classmap" to find out how.
#         - |
#           Add the new `classmap` key in `composer.json` to
#           autoload all classes in the `include` directory.
#         - Run `composer install` again to update the autoloader.
#         - Refresh to see that we're using the new autoloading code!
#     step: composer-autoloading-autoload-legacy-code
#     files:
#         index.php: ~
#         composer.json: ~
#         includes/LegacyHelper.php:
#             read_only: true
#         src/Model/Planet/SolidPlanet.php:
#             read_only: true
#         src/Service/PlanetRenderer.php:
#             read_only: true
#         src/Model/Planet/PlanetInterface.php:
#             read_only: true
#     features:
#         editor: ~
#         browser: ~
#     grading:
#         pending:
#             type: php
#             assertTrue: 1 == 0
#             failure: This can only be done when we have the terminal ability
#         search_for_function:
#             type: php
#             assertFalse: inputContains('index.php', 'spl_autoload_register')
#             failure: Did you add your old custom autoloader back?
#         search_for_require:
#             type: php
#             assertTrue: inputContains('index.php', 'vendor/autoload.php')
#             failure: Did you remove the line that required Composer autoloader? If so, put it back - you still need it!
#         search_for_text:
#             type: php
#             assertTrue: inputContains('composer.json', '"autoload"') and inputContains('composer.json', '"src/"')
#             failure: Did you remove the `autoload` section in `composer.json` that is looking at the `src/` directory of your project? Put that back - you still need it!
#         search_for_require_legacy:
#             type: php
#             assertFalse: inputContains('index.php', 'LegacyHelper.php')
#             failure: Hey, use Composer's autoloader to require `LegacyHelper.php`. This means that you should *not* need to require it in `index.php`.
#         search_for_text_legacy:
#             type: php
#             assertTrue: inputContains('composer.json', '"autoload"') and inputContains('composer.json', '"includes/"')
#             failure: Did you add an `autoload` section to `composer.json` that looks at the `includes/` directory?

# throw-exceptions
# this challenge is not used yet - if you throw an exception, we grade it incorrect
# throwexceptions_validateelementcoding:
#    question: |
#        When you create a `GasPlanet`, you now *must* pass in one of
#        the 4 valid elements. If you don't, `getHexColor()` will fail
#        to return a color and weird things will happen!
#
#        Let's not let that weirdness happen.
#    question_steps:
#        - |
#            In `GasPlanet::__construct()`, add an `if` statement to check
#            if the `$mainElement` argument is *not* one of the 4 valid values
#            (hint, you can use the `getAllElements()` method to help)
#        - |
#            If it is *not* valid, throw a new `Exception` object with
#            the message: `This is not a valid element!`.
#        - |
#            In `index.php`, change the `$planet` variable to use an
#            invalid element - like `gold` (but wouldn't it be cool if
#            a planet were entirely gold!?).
#        - Refresh to see the error!
#    step: throw-exceptions-validate-element
#    files:
#        index.php: ~
#        src/Model/Planet/GasPlanet.php: ~
#        src/Service/PlanetRenderer.php:
#            read_only: true
#        src/Model/Planet/PlanetInterface.php:
#            read_only: true
#    features:
#        editor: ~
#        browser: ~
#    grading:
#        search_for_exception:
#            type: php
#            assertTrue: inputContains('src/Model/Planet/GasPlanet.php', 'Exception')
#            failure: You should throw a new `Exception` object from `GasPlanet::__construct()`.
#        assert_exception:
#            type: http
#            assertTrue: |
#                body() matches "/Fatal error: Uncaught exception 'Exception'/"
#            failure: I don't see the error! Make sure that you're passing an *invalid* element to the `$planet` variable in index.php - like `'gold'`.
#        search_for_message:
#            type: php
#            assertTrue: inputContains('src/Model/Planet/GasPlanet.php', 'This is not a valid element!')
#            failure: "Make sure that your Exception will have the message: `This is not a valid element!` inside of `GasPlanet::__construct()`."
#        look_for_message:
#            type: http
#            assertTrue: body() matches '/with message 'This is not a valid element!'/'
#            failure: "Everything looks ok, but somehow, I don't see the exception message: `This is not a valid element!`."

throwexceptions_catchexceptioncoding:
    question: |
        We've been having a problem with people creating planet objects
        with a *negative* radius. At least as far as we humans understand
        things like gravity and the space-time continuum, that's crazy!

        To help, we've made the PlanetRenderer smarter: if a planet has
        a negative radius, it will throw an exception. Currently, one
        of our 3 planets is causing this exception to be thrown!

        Instead of seeing this error, let's print a little error
        message when that planet is rendered.
    question_steps:
        - |
            In `index.php`, surround the line that may cause an exception
            with a try-catch block
        - |
            If rendering a planet causes an `Exception` to be thrown,
            just print this message: `Planet cannot be rendered`.
    step: throw-exceptions-catch-exception
    files:
        index.php: ~
        src/Model/Planet/GasPlanet.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_for_try_catch:
            type: php
            assertTrue: inputContains('index.php', 'try') and inputContains('index.php', 'catch')
            failure: Did you wrap the code which might throw an exception with a try-catch block?
        search_exception:
            type: http
            assertFalse: |
                body() matches "/Fatal error: Uncaught exception 'Exception'/"
            failure: Hmm, I still see the exception. Did you use a try-catch block to catch the Exception?
        search_for_message:
            type: http
            assertTrue: body() matches '/Planet cannot be rendered/'
            failure: I don't see the text `Planet cannot be rendered` - print that if there is a problem rendering the planet!

throwexceptions_throwexceptiontmc:
    question: |
        Is this code valid?

        ```php
        throw new \DateTime();
        ```
    explanation: |
        Plain and simple: the Exception class is special: it is the
        *only* class that you can `throw`. Well, actually, you can
        throw an `Exception` object or any class that extends it.
    features:
        multiple_choice:
            choices:
                a: |
                    No: you can only use `throw` with the `Exception` class
                    or one of its sub-classes.
                b: |
                    Yes: you can use `throw` with any object to stop execution
                    and show an error.
            correct: a

# exception-classes
exceptionclasses_catchcertainexceptionmc:
    question: |
        We've improved the `PlanetRenderer` to throw an exception if
        a planet has no hex color. Rejoice!

        ```php
        // ...

        class PlanetRenderer
        {
            public function render(PlanetInterface $planet)
            {
                if ($planet->getRadius() < 0) {
                    throw new \Exception('Invalid radius!');
                }

                if (!$planet->getHexColor()) {
                    throw new \Exception('Missing hex color');
                }
            }
        }
        ```

        Can you use a `try-catch` block to *only* catch the
        "Invalid radius!" exception?
    explanation: |
        Answer (A) is just ridiculous - that's *not* real code :).

        You can catch different exception *classes*, but if 2 situations
        both throw the *same* exception class, then it's basically
        *not* possible to catch one exception, but not the other
        (besides checking the exception message... which you should
        *not* do - someone will eventually update that exception message
        and break your code).

        This is why it's sometimes important to throw different exception
        classes in different situations. Let's try that in the next challenge...
    features:
        multiple_choice:
            choices:
                a: |
                    Yes! Just mark that you want to catch the `(first)`
                    exception only:

                    ```php
                    try {
                        echo $renderer->render($planet);
                    } catch (\Exception (first) $e) {
                        // here!
                    }
                    ```

                b: |
                    No. Well, only by checking the exception message,
                    which is really ugly and error-prone;

                    ```php
                    try {
                        echo $renderer->render($planet);
                    } catch (\Exception $e) {
                        if ($e->getMessage() == 'Invalid radius!') {
                            // here!
                        }
                    }
                    ```
            correct: b

exceptionclasses_throwcustomexceptionscoding:
    question: |
        Oh yea! We just made the `PlanetRenderer` even smarter! By
        creating our *own* 2 exception classes (yep, this is legal!),
        we are throwing a different exception when the radius is negative
        versus when the hex color is missing.
    question_steps:
        - Update `index.php` to *only* catch the `InvalidRadiusException` (but don't forget a `use` statement for this Exception class!)
        - |
            Add a *second* `catch` after the first `catch` (yes, this is
            possible!) that will catch the `MissingHexException`. If this
            happens, print the message `Planet has no color`.
        - Reload the page to see it all working!
    step: exception-classes-throw-custom-exceptions
    files:
        index.php: ~
        src/Service/PlanetRenderer.php:
            read_only: true
        src/Exception/InvalidRadiusException.php:
            read_only: true
        src/Exception/MissingHexException.php:
            read_only: true
        src/Model/Planet/GasPlanet.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_exception_1:
            type: php
            assertTrue: inputContains('index.php', 'Exception\\InvalidRadiusException')
            failure: Did you catch an `InvalidRadiusException` exception?
        search_exception_2:
            type: php
            assertTrue: inputContains('index.php', 'Exception\\MissingHexException')
            failure: Did you catch a `MissingHexException` exception?
        search_for_message_1:
            type: http
            assertTrue: body() matches '/Planet cannot be rendered/'
            failure: Did you print `Planet cannot be rendered` when an `InvalidRadiusException` is thrown?
        search_for_message_2:
            type: http
            assertTrue: body() matches '/Planet has no color/'
            failure: Did you print `Planet has no color` when a `MissingHexException` exception is thrown?

# magic-methods
magicmethods_printobjectscoding:
    question: |
        Let's take our planet classes out for a real test drive: and
        render the 8 (sorry Pluto) planets in our solar system!

        Before doing this, we've given each class a `$name` property
        so we can print it before rendering the planet. Everything
        is *almost* working, but when we print the `$planet` variable,
        it gives us an error!
    question_steps:
        - Refresh the page or check the code to see the error!
        - |
            Update both `SolidPlanet` and `GasPlanet` so that
            when you print them, it prints the planet's name.
        - Refresh and enjoy the solar system :p
    step: magic-methods-print-objects
    files:
        src/Model/Planet/SolidPlanet.php: ~
        src/Model/Planet/GasPlanet.php: ~
        index.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_method_1:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\SolidPlanet').hasMethod('__toString')
            failure: The `Model\Planet\SolidPlanet` class should have the magic method which allow printing objects.
        search_method_2:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\GasPlanet').hasMethod('__toString')
            failure: The `Model\Planet\GasPlanet` class should have the magic method which allows printing objects.

magicmethods_setprivatepropertycoding:
    question: |
        The `GasPlanet` has a private `$name` property, but it does *not*
        have a `setName()` method. This means that the `$name` property
        cannot be modified, which normally, is probably OK!

        But, let's challenge ourselves! In `index.php`, we've added some
        code that tries to change Neptune's name by referencing the property
        directly. That won't work! Yet... Let's make this possible!
    question_steps:
        - |
            Keep the `$name` property private, but add
            a magic `__set()` method to `GasPlanet` that makes the code
            in `index.php` work!
        - Reload and make sure it works!
    step: magic-methods-set-method
    files:
        src/Model/Planet/GasPlanet.php: ~
        src/Model/Planet/SolidPlanet.php:
            read_only: true
        index.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_method:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\GasPlanet').hasMethod('__set')
            failure: The `Model\Planet\GasPlanet` class needs a magic `__set()` method - bit I don't see this!.
        check_output:
            type: http
            assertTrue: body() matches '/Nep-Toon/'
            failure: I don't see `Nep-Toon` (the new name we have the planet) in the output! Did you set it right in the `__set()` magic method?

magicmethods_adddesctructmethodcoding:
    question: |
        We already know that you can create a method that will
        be called whenever an object is instantiated/constructed.
        This is called `__construct()`.

        And while it's much less common, you can *also* create a
        method whenever an object is *destructed*  - it's called
        `__destruct()`. This is usually called at the very end of
        your script, but may be called earlier - once you're done
        working with your object.
    question_steps:
        - Add a `__destruct()` method to `GasPlanet`. Inside, just `echo $this->name`.
        - 'Refresh to see if this method is called! Hint: scroll to the bottom of the output.'
    step: magic-methods-add-destruct-method
    files:
        src/Model/Planet/GasPlanet.php: ~
        src/Model/Planet/SolidPlanet.php:
            read_only: true
        index.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        search_method:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\GasPlanet').hasMethod('__destruct')
            failure: I don't see the `__destruct()` magic method in `Model\Planet\GasPlanet`.

# array-access
arrayaccess_implementingarrayaccesscoding:
    question: |
        Our app *also* deals with meteoroids: those cute
        little flying rocks that occasionally threaten
        life itself on Earth. Yay!

        Since a meteoroid is just a chunk of different metals,
        we've given it an `elements` property to hold whatever
        metals it has. Let's print these... by treating this
        class like an array!
    question_steps:
        - |
            Implement the `ArrayAccess` interface and add the
            4 methods you need to your class: `offsetExists($offset)`,
            `offsetGet($offset)`, `offsetSet($offset, $value)` and `offsetUnset($offset)`.
        - |
            Fill in the logic for each method so that we can
            access the `$elements` property like an array.
        - |
            In `metor.php`, print the `Iron`, `Nickel` and `Cobalt`
            masses in the correct table boxes.
    step: arrayaccess-implement-arrayaccess
    files:
        metor.php: ~
        Meteoroid.php: ~
    features:
        editor: ~
        browser:
            default_uri: metor.php
    grading:
        assert_implementing:
            type: php
            assertTrue: reflection_class('\Meteoroid').implementsInterface('\ArrayAccess')
            failure: The `Meteoroid` class should implement the `ArrayAccess` interface.
        search_for_array_call:
            type: php
            assertTrue: inputContains('metor.php', '$meteoroid[')
            failure: Did you use the `$meteoroid` variable like an array to print each element's mass in the table?
        check_output:
            type: http
            assertTrue: body() matches '/45712/'
            failure: I don't see `45712` (the mass of Iron) in the output. Are you printing this?

arrayaccess_arrayorobjectmc:
    question: |
        Challenge! Check out the following code:

        ```php
        // some code that you can't see!

        echo $planet['radius']; // prints 50

        echo $planet['atmosphere']->getMainElement(); // prints Nitrogen

        echo $blackhole; // prints an empty string

        $solarSystem[] = $planet;
        ```

        Which of the following is **not** true:
    explanation: |
        Things are never as simple as they seem!

        A) `$planet` is used like an array, but we know that this
        could be because it's an array *or* an object that
        implements `ArrayAccess`.

        B) `$solarSystem` is *also* used like an array with the
        `$solarSystem[] = $planet;` syntax. So this might *also*
        be an object!

        C) If `$blackHole` is an object that has a `__toString()`
        method, then we could of course print this.

        D) Because of the code `$planet['atmosphere']->getMainElement();`,
        we know that `$planet['atmosphere']` must be an object. You
        can *only* call a method on an object.
    features:
        multiple_choice:
            choices:
                a: "`$planet` could be an array *or* an object"
                b: "`$solarSystem` is definitely an array"
                c: "`$blackHole` could be a string or an object"
                d: "`$planet['atmosphere']` is definitely an object"
            correct: b

# iterator-aggregate
iteratoraggregate_implementinterfacecoding:
    question: |
        Hey hey! Someone got fancy and created a new `SolarSystem`
        class that holds all of the planets. Cool!

        Just one problem: the page isn't working anymore! We're trying
        to loop over the `$solarSystem` object, and that just isn't working.
    question_steps:
        - Add the `IteratorAggregate` interface to `SolarSystem`
        - |
            Add the `getIterator()` method so that we can loop
            over the `$planets` property.
        - Reload and enjoy the planets again!
    step: iteratoraggregate-implement-interface
    files:
        src/Model/Planet/SolarSystem.php: ~
        index.php:
            read_only: true
        src/Model/Planet/GasPlanet.php:
            read_only: true
        src/Model/Planet/SolidPlanet.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_implementing:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\SolarSystem').implementsInterface('\IteratorAggregate')
            failure: The `SolarSystem` class should implement the `IteratorAggregate` interface.
        assert_object:
            type: php
            assertTrue: get_class(variable('solarSystem').getIterator()) === 'ArrayIterator'
            failure: The `getIterator()` method should return an `ArrayIterator` object.
        check_output:
            type: http
            assertTrue: body() matches '/Jupiter/'
            failure: "I don't see the planets being printed! Something still isn't right..."

iteratoraggregate_countplanetscoding:
    question: |
        Since the number of planets apparently changes sometimes, we
        want to print the current number of planets at the top of the
        page.

        We asked the intern to do it, but he couldn't figure it out.
        Sure, we can *loop* over the `SolarSystem` object, but we can't
        seem to count it (he tried in `index.php` - it always says 1!).
    question_steps:
        - |
            Add a new interface: `Countable`. This will allow
            you to "count" an object.
        - |
            Implement any method(s) that you need for this
            interface (put on your Googling/Binging hat and research
            the answer!)
    step: iteratoraggregate-count-planets
    files:
        src/Model/Planet/SolarSystem.php: ~
        index.php:
            read_only: true
        src/Model/Planet/GasPlanet.php:
            read_only: true
        src/Model/Planet/SolidPlanet.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        assert_implementing_1:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\SolarSystem').implementsInterface('\IteratorAggregate')
            failure: The class `SolarSystem` should *still* implement the `IteratorAggregate` interface - bring him back!
        assert_implementing_2:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\SolarSystem').implementsInterface('\Countable')
            failure: The class `SolarSystem` should also implement a new `Countable` interface.
        assert_value:
            type: php
            assertTrue: variable('solarSystem').count() == 8
            failure: "Hm, we should have 8 planets in our solar system, but the `count()` method is returning a different number. Is your logic in `count()` correct?"
# traits-reuse
traitsreuse_reusenamecoding:
    question: |
        Check out `GasPlanet` and `SolidPlanet`: they have a bit
        of duplication! Each has a `$name` property, a `getName()`
        function and a `setName()` function.

        I hate duplication!
    question_steps:
        - |
            Create a new trait: `NameableItemTrait` (and don't forget to give it
            the correct `namespace`!)
        - |
            Move the `$name` property and the 2 duplicated methods
            into this trait.
        - |
            Use the trait from both planet classes and delete that
            duplicated code!
    step: traits-reuse-reuse-name
    files:
        src/Model/Planet/NameableItemTrait.php: ~
        src/Model/Planet/GasPlanet.php: ~
        src/Model/Planet/SolidPlanet.php: ~
        src/Model/Planet/SolarSystem.php:
            read_only: true
        index.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
        src/Service/PlanetRenderer.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        # @TODO Add trait_exists() support to the PHP provider
        #        assert_class_exist:
        #            type: php
        #            assertTrue: trait_exists('\\Model\\Planet\\NameableItemTrait')
        #            failure: The `Model\Planet\NameableItemTrait` trait does not exist! Did you create it?
        assert_is_trait:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\NameableItemTrait').isTrait()
            failure: Make sure to create `Model\Planet\NameableItemTrait` and make it a `trait`.
        search_methods:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\NameableItemTrait').hasMethod('setName') and reflection_class('\\Model\\Planet\\NameableItemTrait').hasMethod('getName')
            failure: Move `setName()` and `getName()` methods into the `Model\Planet\NameableItemTrait` trait.
        search_property:
            type: php
            assertTrue: reflection_class('\\Model\\Planet\\NameableItemTrait').hasProperty('name')
            failure: Move the `$name` property into the `Model\Planet\NameableItemTrait` trait.
        search_trait:
            type: php
            assertTrue: inputContains('src/Model/Planet/SolidPlanet.php', 'NameableItemTrait') and inputContains('src/Model/Planet/GasPlanet.php', 'NameableItemTrait')
            failure: MAke sure that `SolidPlanet` and `GasPlanet` use the `NameableItemTrait` trait.
        search_moved_methods_1:
            type: php
            assertFalse: inputContains('src/Model/Planet/SolidPlanet.php', 'function setName') or inputContains('src/Model/Planet/SolidPlanet.php', 'function getName')
            failure: "Now that it uses the trait, the `SolidPlanet` class doesn't need to have the `setName()` and `getName()` methods anymore! Yay!"
        search_moved_methods_2:
            type: php
            assertFalse: inputContains('src/Model/Planet/GasPlanet.php', 'function setName') or inputContains('src/Model/Planet/GasPlanet.php', 'function getName')
            failure: "Now that it uses the trait, the `GasPlanet` class doesn't need to have the `setName()` and `getName()` methods anymore! Yay!"

traitsreuse_inheritancevstraitsmc:
    question: |
        In the previous challenge, we created a `NameableItemTrait`
        and used it inside of `GasPlanet` and `SolidPlanet`.

        But, there was another option: create a new `AbstractPlanet`
        class, move the logic there, and then *extend* this class.

        In this situation, what was a better option: using a `trait`
        or extending a base `class`?
    explanation: |
        Traits versus extending a class: the correct answer always depends
        on your situation. If both classes are modeling the same type
        of thing (e.g. a `Planet`), then extending a base class may make
        sense. If not, definitely use a `trait`.

        And if you want, you could do both! Use a trait inside of the
        base class!

        ```php
        abstract class AbstractPlanet implements PlanetInterface
        {
            use NameableItemTrait;
        }
        ```
    features:
        multiple_choice:
            choices:
                a: |
                    The trait is better because it would allow us to add
                    this trait to *other* future classes that have a name, but
                    aren't planets (e.g. the `Meteoroid` class).
                b: |
                    The abstract class is better: these are both *planets*,
                    so it makes sense to give these the same base `AbstractPlanet`
                    class.
                c: Both of these are correct!
            correct: c

# composition-ftw
compositionftw_overrideclasscoding:
    question: |
        Remember our trusty `PlanetRenderer` class? For this challenge,
        pretend that you *cannot* edit it: because this is a class
        from an external library that you're using.

        But here's the challenge: the existing `PlanetRenderer` returns
        a `div` around the planet. But to allow for some extra
        styling, *we* need to add a *class* to this div: `rendered-planet`.
        Unfortunately, it doesn't look like there's any easy way to
        do this.

        Let's fix this by overriding the class!
    question_steps:
        - |
            Create a new `CustomPlanetRenderer` and make it extend
            `PlanetRenderer`.
        - |
            Override the `render(PlanetInterface $planet)` method (and don't
            forget that you'll need a `use` statement for `PlanetInterface`)
        - |
            Call the [parent()](http://knpuniversity.com/screencast/oo-ep3/parent)
            method, but then wrap the string in a new div - something like this:

            ```php
            $html = parent::render($planet);

            return sprintf('<div class="rendered-planet">%s</div>', $html);
            ```
        - |
            Change `index.php` to instantiate *our* class instead of the
            normal one.
    step: composition-ftw-create-custom-planet-renderer
    files:
        index.php: ~
        src/Service/CustomPlanetRenderer.php: ~
        src/Service/PlanetRenderer.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_class:
            type: php
            assertTrue: class_exists('\\Service\\CustomPlanetRenderer')
            failure: The `Service\CustomPlanetRenderer` class does not exist! Did you create it?
        assert_subclass_of:
            type: php
            assertTrue: reflection_class('\\Service\\CustomPlanetRenderer').isSubclassOf('\\Service\\PlanetRenderer')
            failure: The `CustomPlanetRenderer` class should extend `PlanetRenderer` one.
        search_for_render_override:
            type: php
            assertTrue: inputContains('src/Service/CustomPlanetRenderer.php', 'render')
            failure: Make sure that you override the `render()` method in `CustomPlanetRenderer`!
        search_for_parent_call:
            type: php
            assertTrue: inputContains('src/Service/CustomPlanetRenderer.php', 'parent::render')
            failure: You should call the `parent()` method inside of `render()`.
        assert_class:
            type: php
            assertTrue: get_class(variable('renderer')) === 'Service\\CustomPlanetRenderer'
            failure: Use our new `CustomPlanetRenderer` class instead of `PlanetRenderer` in `index.php`
        search_css_class:
            type: http
            assertTrue: body() matches '/rendered-planet/'
            failure: Did you render each planet in a div with a `rendered-planet` CSS class? Check the output and update your `render()` method if needed!

compositionftw_usecompositioncoding:
    question: |
        Extending the class worked *just* fine. But let's try composition!
        *If* the class you want to replace implements an interface or extends
        a base class, then you can implement/extend *that* instead and
        *wrap* the object you want to fake.

        This is much more difficult at first - but is a great skill to
        understand and master.
    question_steps:
        - |
            Instead of extending `PlanetRenderer`, make `CustomPlanetRenderer`
            implement the new `PlanetRendererInterface`
        - |
            Add a `__construct()` method to `CustomPlanetRenderer` that accepts a
            single argument: a `PlanetRendererInterface` object. Set this on a new
            `planetRenderer` property.
        - |
            Update `CustomPlanetRenderer` to call `render()` on the new
            `planetRenderer` property and *then* add the new div with
            `rendered-planet` CSS class like before.
        - |
            Update `index.php`: When you instantiate your `CustomPlanetRenderer`,
            you will now need to instantiate and pass the normal one to it.
    step: composition-ftw-use-composition
    files:
        index.php: ~
        src/Service/CustomPlanetRenderer.php: ~
        src/Service/PlanetRenderer.php:
            read_only: true
        src/Service/PlanetRendererInterface.php:
            read_only: true
        src/Model/Planet/PlanetInterface.php:
            read_only: true
    features:
        editor: ~
        browser: ~
    grading:
        check_class:
            type: php
            assertTrue: class_exists('\\Service\\CustomPlanetRenderer')
            failure: The `Service\CustomPlanetRenderer` class does not exist! Did you rename it?
        assert_subclass_of:
            type: php
            assertFalse: reflection_class('\\Service\\CustomPlanetRenderer').isSubclassOf('\\Service\\PlanetRenderer')
            failure: The `CustomPlanetRenderer` class should NOT extend `PlanetRenderer` anymore.
        assert_implementing:
            type: php
            assertTrue: reflection_class('\\Service\\CustomPlanetRenderer').implementsInterface('\\Service\\PlanetRendererInterface')
            failure: The `CustomPlanetRenderer` class should implement `PlanetRendererInterface`.
        assert_class:
            type: php
            assertTrue: get_class(variable('renderer')) === 'Service\\CustomPlanetRenderer'
            failure: The `$renderer` variable should be an instance of `CustomPlanetRenderer` class instead of `PlanetRenderer` in `index.php`
        assert_construct_exists:
            type: php
            assertTrue: method_exists(variable('renderer'), '__construct')
            failure: Make sure your `CustomPlanetRenderer` has a `__construct()` method.
        search_css_class:
            type: http
            assertTrue: body() matches '/rendered-planet/'
            failure: Did you render each planet in a div witha  `rendered-planet` CSS class? Check the output.

compositionftw_compositionmc:
    question: |
        In the previous challenge, we changed from overriding a class
        to using composition. It was honestly a bit more work! What
        are the advantages?
    explanation: |
        Don't get too excited or worried about composition. In most
        cases, the advantages are small, and are most enjoyed by
        third-party library creators, who use composition to add
        extra flexiblity to their libraries that we may never need
        in our application!

        Just get used to seeing the pattern and understanding what
        it means.
    features:
        multiple_choice:
            choices:
                a: |
                    Composition makes your execute faster: because calling
                    parent methods can be slow
                b: |
                    There aren't any real advantages: both are valid ways
                    to override functionality.
                c: |
                    With composition, your new class - `CustomPlanetRenderer`
                    can be used to decorate/enhance *any* other classes that
                    implement `PlanetRendererInterface`.
            correct: c