We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. Offtopic

Unsuffixed actions + annotations :: Just an idea for coders to discuss a little

Annotations is a cool feature =) Look at this class:

<?php

namespace Controller;

use Phalcon;

class Comment extends Phalcon\Mvc\Controller
{
    /**
     * @Action
     */
    public function index()
    {

    }

    /**
     * @Action
     */
    public function show()
    {

    }

    /**
     * Doing something secret...
     */
    public function internalMethod()
    {

    }
}

Isn't it pretty tidily? (Suffixes could be "disabled" by $dispatcher->setControllerSuffix('') & $dispatcher->setActionSuffix('') if someone don't know). With beforeExecuteRoute event you can easily allow only @Action-annotated methods to be dispatched. So you can have easy-to-understand, simple, tidily code and an the same time still safe.

2


40.8k

What is benefit for this shortcuts? Less typing - more problems later :)



39.3k

The problem I see is that the benefit from having sortcuts such as the ones you suggest will slow down the framework. Annotations are a great feature but they come with a cost and that cost is performance. Phalcon will have to parse the annotations, understand what they mean and do the appropriate action.

It is like any kind of OO programming, using straight up PHP vs. using a class is always faster because PHP will not need to have the overhead of the class. The same applies with annotations.

Now typing showAction vs. having the annotation @Action seems like a good idea but your code will lose performance because a new step will be introduced into Phalcon i.e. the step to parse the annotation and understand its purpose so that it can execute what is needed.

With Phalcon we are trying as much as possible to cater for user requests but not to the expense of making the framework slower. We introduced annotations because a lot of people wanted them despite the fact that they slow the framework down. As long as the user knows about this then we are all good. Logical ways of implementation were for instance routing but with all do respect your example offers little help to the developer. Typing 

  /**
   * @Action
   */
  public function show()
  {

  }

vs.

  public function showAction()
  {

  }

is not offering much to the developer while introducing another layer of complexity/slowness as I explained above.

That is my personal opinion and again no offense.



32.4k

Well, any tidily costs resources =) This annotation is just keeping methods' names more "cleanness". Of course, keep methods unsuffixed is not necessary for most cases, but may be useful for some of them. For some interproject integration... or something like... =) I don't propose new issue but just an idea/conception. Because there is no other phalcon-related forum for this =)



11.0k

@Eavu it's an idea/conception that i follow. Even in classnames. At the opposite of standardized practices, i personally rather remove any redundance of classnames such as controllers ! a php file in a "controller" folder is de facto a controller, but yes, i need to namespace it in Controller\Index. sorry for digressing.

@Nikolaos, Sorry I didn't opened C-Source to check it... Just for theorical purpose, not (yet) request feature. I'm already using @Route annotation. should we get significant overhead if that code works (2 ways "index" and "indexAction" for backward compatibility) ?

/**
 * @Route(...)
 */
public function index()
{
}