[NFR] Implement interfaces for the Phalcon components so that they can be easily extendable

[Nikolaos Dimopoulos]

Description

The framework should provide the ability for developers to replace common components with their own implementations by using interfaces that Phalcon would understand. This calls for generation of interfaces for most components.

Rules

• For most components an interface must be created that components will use

Examples

• \Phalcon\Logger\Interface
• \Phalcon\Logger\Adapter\File implements it
• \Phalcon\Logger\Adapter\Db\MySql can use it (component not available yet)
• \Phalcon\Logger\Adapter\Db\Postgresql can use it (component not available yet)
• \Phalcon\Logger\Adapter\Db\Sqlite can use it (component not available yet)

• \Phalcon\Translate\Interface
• \Phalcon\Translate\Adapter\NativeArray implements it
• \Phalcon\Translate\Adapter\Gettext can use it (component not available yet)
• \Phalcon\Translate\Adapter\Csv can use it (component not available yet)

[hdo...@gmail.com]

What about just "adapter" interface/abstract instead of "interface".

I used Phalcon\Mail\Transport abstract class for mail component, which "PHP" transport adapter extends it, and I check it strictly if transport class is instance of Phalcon\Mail\Transport class (else it throws an exception). And transport adapters should have protected abstract "send" method (just defined it as abstract in phalcon.h and implement dummy/empty send method). So I don't have to check if it has "send" method or not (phalcon_method_exists), just fire adapter's "send" method.

So

Phalcon\Logger\Adapter (dummy adapter class - log/begin/commit/rollback/etc methods must be implemented)

Phalcon\Logger\Adapter\File extends from Phalcon\Logger\Adapter

Phalcon\Translate\Adapter (dummy adapter class - query/exists/etc methods must be implemented)

Phalcon\Translate\Adapter\NativeArray extends from Phalcon\Translate\Adapter

Phalcon\Mail\Transport (dummy adapter class - send method must be implemented)

Phalcon\Mail\Transport\PHP extends from Phalcon\Mail\Transport

Same for session, cache backends, etc.

[Nikolaos Dimopoulos]

That is perfectly fine.

The actual design decision will be taken as soon as work for 0.7.0 starts which will be Nov 05, 2012 onward. We can have discussions about this and suggestions so as to get to a conclusion that would benefit the framework as well as the developers :)

We can have a hangout if you guys like to throw ideas around.

Nikos

[hdo...@gmail.com]

Which naming convention has been accepted?

[Andres-Gutierrez]

Since \Phalcon\Logger\Interface isn't a valid class name, I'm appending "Interface" to the current class names:

\Phalcon\Http\ResponseInterface
\Phalcon\Logger\AdapterInterface
\Phalcon\FlashInterface

2012/11/10 hdo...@gmail.com <hdo...@gmail.com>

--
 
 

[hdo...@gmail.com]

Is "Interface" used by PHP internals/source-code?

[Andres-Gutierrez]

Is a reserved keyword, try this:

interface Phalcon\Logger\Interface {

}

Parse error: syntax error, unexpected T_NS_SEPARATOR, expecting '{' in /www/c.php on line 3

2012/11/10 hdo...@gmail.com <hdo...@gmail.com>

--
 
 

[hdo...@gmail.com]

Crap! I think the reason is "interface" keyword and case insensitivity :/