A suggestion for improvement of annotations

[jaimz22]

I've been working on modifying the Restler-Framework for my own special project needs. and I've got a few suggestions.

Don't reinvent the wheel! someone else has already made a wheel... and it's more round than yours!
No offense to anyone what so ever, I personally love writing all my own code, even if someone else has done it before. But recently with Composer and Packagist.com my view of that has changed. You should take advantage of it. Restler is a AWESOME package to have. In my opinion it's the best way to do REST for PHP, quick and easy. Using just a few packages can help you speed past some technical issues and get to the core functionality of what Restler is. My suggestions for this:

• Drop the Scope class, it's really not a dependency injection container. It can't handle class inheritance, it doesn't understand the automatic resolution of constructor parameters. Use something else! lluminate/Container for instance, which is really nice and super easy to use.
• Don't create your own annotation driver! Hey, Annotations are hard, luckily someone has already figured it out and made it easy. Use Doctrine/Annotations. I simply can't stress how powerful doctrine annotations are. each annotation is a class, the annotations can be cached. it's simply smooth sailing with Doctrine/Annotations!
• Autoloader.php... really come on now, just use the composer autoloader, it's pretty much the best at what it does.

One thing that really kind of bugs me is PSR-2's 80 char line limit... it makes reading the Restler code kind of hard. I can only assume that you write your code, then run it through a formatter. I know I couldn't site and write my code that way! This is a bit nit-picky but honestly it's hard to read stuff. for instance, in Explorer.php there is this code:

$this->setType(
            $r,
            new ValidationInfo(Util::nestedValue($m, 'return') ? : array())
        );

why not just let it be:

$this->setType($r, new ValidationInfo(Util::nestedValue($m, 'return') ? : array()));

One last thing, organize the interfaces some how, you've got about 10 - 12 interfaces just kind of sitting the in the root source directory, create a directory(namespace) called Contracts, and put the interfaces in it just to help organize, Luracast\Restler\Contracts\iFilter() isn't so bad!

I just want to say again, I really enjoy working with Restler. I hope i'm not coming off as being rude. I greatly appreciate the work you put into Restler, as i'm sure many people do. And I always have great respect for people who comment their code (bravo!) I just know that you're putting a lot of effort into doing things that other people have already done, and I'd like to see you be able to focus on the core of what Restler is, instead of focusing your efforts on supporting classes like dependency inject containers

[Arul-]

@jaimz22 thanks for your suggestions, I will surely consider them!

Annotations

Regarding annotations, there is a reason why I choose to write my own. In my opinion Doctrine/Annotations are cloned from the java world and does not adhere fully to the phpdoc style

I wanted annotations to be non intrusive (should not mess with class documentation generators), where as can add to the same principles.

Having two levels of defining things makes it best of both worlds, say for example

@param string $email {@type email}

makes the type for generic php api as string where as restler knows to validate it as email!

Scope

There are definitely plans to improve and expand scope, will share more info later

Autoloader

I'm all in, to remove the Autoloader, but some users still demand leaving it there

Even now, it is only used until you run composer install then composer autoloader takes over

[Arul-]

I agree with organising interfaces, it is already in the road map. regarding PSR-2, I just want to stick to one standard. Recommend something that you see fit!

[alexkb]

There are definitely plans to improve and expand scope, will share more info later

Hi Arul, do you have anymore information on this? We're starting to use it more, and have expanded upon the default scope table that bshaffer propose's, but don't want to be going off on a tangent..

[Arul-]

@alexkb the scope table bshaffer is proposing and the scope I'm talking about are two different things.

I'm talking about Scope class here, we already have some progress in RC6

Now it is possible to use your favourite container to resolve a dependency. See #330 (comment) for more info