Able interfaces v1

[antonkomarev]

Notice: This is just a concept for the future, it doesn't mean it would be 100% implemented. Sharing my thoughts with community to receive feedback.

Current implementation

• Cog\Contracts\Love\Reacter\Models\Reacter is connected with polymorphic models via Cog\Contracts\Love\Reacterable\Models\Reacterable interface.
• Cog\Contracts\Love\Reactant\Models\Reactant is connected with polymorphic models via Cog\Contracts\Love\Reactable\Models\Reactable interface.

Rules

• When the base word is a complete and recognizable word, you will usually use -able.
• When the base word ends in -e, you should remove ending -e, then add -able. Leave the -e when the word ends in -ce or -ge.
• If you must double the final consonant of the base word or change the final -y to -i, add -able.
• In general, -ible is less common and the base word is not a complete and recognizable word.

However, there are some exceptions from these rules.

Motivation

Pattern is simple - just add able to model name and you'll get polymorphic model interface name.

But there are exceptions:

• not all words has related words with -able suffix (in that case I just ignore that and add this word to my vocabulary);
• some words has related words with -able suffix, but they are writing a bit different, for example for word Reactant there is no word Reactantable, but Reactable exist.

Idea

Polymorphic model contract must have Able class name and be inside of the namespace of the model to which access is providing. There is no need to have more than one entry point for accessing model methods.

• Cog\Contracts\Love\Reacter\Models\ReacterInterface is connected with polymorphic models via Cog\Contracts\Love\Reacter\Able\Models\AbleInterface interface.
• Cog\Contracts\Love\Reactant\Models\ReactantInterface is connected with polymorphic models via Cog\Contracts\Love\Reactant\Able\Models\AbleInterface interface.

use Cog\Contracts\Love\{
    Reactant\Able\Models\AbleInterface as ReactantAbleInterface,
    Reacter\Able\Models\AbleInterface as ReacterAbleInterface
};
use Cog\Laravel\Love\{
    Reactant\Able\Models\Traits\Able as ReactantAble,
    Reacter\Able\Models\Traits\Able as ReacterAble
};

class User implements
    ReacterAbleInterface,
    ReactantAbleInterface
{
    use ReacterAble;
    use ReactantAble;
}

System Design

Things to consider

1. Right now traits has methods bootReactable & bootReacterable, but with new implementation both of the traits will have bootAble methods, will it work if model uses both of the traits?

2. This concept could be extracted to Cog\Laravel\Able package.

3. We can create AbstractAble class with:

abstract class AbstractAble
{
    // TODO: abstract name 
    public function isRegisteredAsLoveReactant(): bool;

    // TODO: abstract name
    public function isNotRegisteredAsLoveReactant(): bool;

    // TODO: abstract name
    public function registerAsLoveReactant(): void;
}

Alternative

There is another one possible concept on my mind. We can ignore the correctness of spelling by adding capitalized *Able suffix to the names and it will be perceived as 2 worded names:

• Cog\Contracts\Love\ReacterAble\Models\ReacterAbleInterface
• Cog\Contracts\Love\ReactantAble\Models\ReactantAbleInterface

It will be very useful for such names like Individual which has -able suffixed form as Individable.