composer

[lleitep3]

create a composer.json

[wesleyvicthor]

the composer have their own loader.

[lleitep3]

yes, but if someone prefer to use the Respect/Louder than Composer loader, can't be an option?

[wesleyvicthor]

I dunno. For me if I already using composer I don't see the needed to use Respect/Loader.

[nickl-]

As far as I know the Respect loader looks for the presence of vendor/autoload.php first before falling back on our own psr-0 loader. see tests/bootstrap.php

<?php

/**
 * PSR-0 compliant autoloader created by Composer.
 * If this file does not exist, run `composer.phar install` from
 * the project root directory to generate it.
 */
if (!($autoload = @include __DIR__ . '/../vendor/autoload.php')) {

    /* Include path */
    set_include_path(implode(PATH_SEPARATOR, array(
        __DIR__ . '/../library',
.........
vvvvvv
Continues with Respect autoloader...

[nickl-]

Plus why would you suggest the loader needs a uhm loader? I'm confused.

All the scripts pear, packagist and a bunch of other cool stuff are automated see Respect/Foundation all you have to do is grab the Makefile, put that in your project folder and start with.

make foundation

Doesn't really get much cooler than that =D

[augustohp]

I think there are cases this could be quite useful. I myself don't like the composer autoload at all... but this is quite a personal question.

Loader could be used in another projects (people already have) and be easily installed with composer, minding they don't use the composer PSR #0 autoloader and use their own implementations. I really don't know how tied the usage of composer's autoload implementation are with the composer utilization itself, do you really think all the people that use composer uses it's autoloader?

Even assuming that is 100% sure, we still have ways of having libraries installed with PEAR, Onion and so on that are not supported by the Composer's autoload implementation, Respect\Loader can quite easily cover this gap. I agree on the idea in a way it should cover things the Composer's autoload doesn't cover.

@lleitep3 You thoughts on it are just a simple composer.json to make Loader available in Packagist? We could try and use Foundation to publish it there, but we really have to try it out and see if it works provided Loader does not have its own directory. Let's see how it goes... ideally the nicest thing is to use Foundation, but if doesn't works we can provide just the composer.json while we make Foundation work for projects that have just a classe in the package.

@nickl- Loader does not have it, what happens is that @henriquemoody put it directly into the bootstrap.php. But it would be quite nice to have it done directly into Loader as you said =D

What do you think on the key implementations on this issue?

• Make Loader available in Packagist ( @lleitep3 idea )
• Support for composer's autoload (if present) than the fallback to the current autoload implementation ( as @nickl- commented )

[wesleyvicthor]

I like the fallback ideia (;

[nickl-]

As said before I really haven't paid much attention to the script outside of bootstrap. But this is precisely how it should be, I don't have high expectations from an autoloader it should just work. You don't know about it as long as everything works but then when it doesn't well, how quick can it sort itself out again is the question.

I would be happy if Respect/Loader understands the composer tree to never work with vendor/autoload again, it is truly primitive. IMO I think we have projects that I would rather get packaged first and think people would find more use for some of our other projects, would you agree?

Besides the obvious that it gets tested and supports current packaging I would love to see loaders be slightly more intelligent, would they be able to know if they found a duplicate reference, to make a note about preventing it or prompt you for a choice next time you launch php. It should be able to give a report of what it's done and allow it's scop to be increased or deceased. hmmm am I asking too much again? =)

[lleitep3]

So, I don't like so much the Composer/Loader too, Composer Tool is so good, but, bothers me see all projects i need in my vendor path, I just need the lib them, I'm working to resolve this.

[nickl-]

I agree with the vendor notion, which probably comes from js and others.
You libs go into lib or library which is the source you have to maintain.
Web goes into public or www or htdocs or some strange combination that M$ came up with.
Executables go in bin.
Configs should go in etc, cfg or ini folder and composer should symlink these to installation ala bin-dir functionality. I've tried it only does bin folders for some strange reason.
Tests go in test or tests no other name for that.

Application can have an app folder if you want to separate from lib but vendor denotes outside/external libraries which evolve outside of your control and they need to be managed and not mixed in with your code. You can't save yourself deprecation and other issues related to updates without exposing yourself to security exploits or disastrous bugs which have been corrected and you just don't know about it. Hence why we want need the use of a packager/manager to track dependencies and version incompatibilities in so simplifying our task of managing these external libraries.

Unless you are just referring to vendor libs as your libs then it's 6 of twelve or half a dozen and we're not smelling the roses but require a spade that does the trick, call it what you may.

[henriquemoody]

What happens in the tests/bootstrap.php file does not matter for composer, but if we put the fallback into Loader we will create a dependence for all Respect packages, thus if someone is using a Respect component with composer, it's will install automatically Loader for nothing.
I prefer keep the current fallback in the tests/bootstrap.php file but I agree to put Loader in Packagist.

[nickl-]

I think it is a mistake to have an autoloader in bootstrap!

bootstrap should just include the autoloader from elsewhere.

if not we start using test/bootstrap with hooks requires from public and bin and who knows where else. I would see a stop to this.

[nickl-]

So what about this:

<?php

date_default_timezone_set('UTC');

$paths = explode(PATH_SEPARATOR,get_include_path());
array_unshift($paths, '../library');
if (file_exists('../vendor/composer')) {
    $map = require '../vendor/composer/autoload_namespaces.php';
    foreach ($map as $path)
        $paths[] = $path;
}

$paths[] = trim(`pear config-get php_dir`);
set_include_path(implode(PATH_SEPARATOR, array_unique($paths))); 

/**
 * Autoloader that implements the PSR-0 spec for interoperability between
 * PHP software.
 */
spl_autoload_register(
    function($className) {
        static $composerClassmap;
        if (!isset($composerClassmap) && file_exists('../vendor/composer'))
               $composerClassmap = require '../vendor/composer/autoload_classmap.php';

        if (isset($composerClassmap[$className]))
            return require $composerClassmap[$className];

        $fileParts = explode('\\', ltrim($className, '\\'));

        if (false !== strpos(end($fileParts), '_'))
            array_splice($fileParts, -1, 1, explode('_', current($fileParts)));

        $file = implode(DIRECTORY_SEPARATOR, $fileParts) . '.php';

        foreach (explode(PATH_SEPARATOR, get_include_path()) as $path) {
            if (file_exists($path = $path . DIRECTORY_SEPARATOR . $file))
                return require $path;
        }
    }
);

With this our PSR-0 loader is able to detect the presence of composer and is now fully capable of extending it's reach to include the composer installed libraries without using the composer autoloader. It's just been bugging me mad that we are delegating to composer when we are more than capable.

What are your thoughts? @lleitep3 is this what you had in mind?

Now the question is where should it go, as mentioned before the test folder is not optimal because not only tests will use this and bootstrapping to ../test/bootstrap.php just looks weird IMO. Maybe a bootloader belongs in the root now that I think about it, so we don't have to do the dot-dot-slashes anymore. I wonder...

[nickl-]

Then just as you think it surely can't get anymore WOW than that, right? Every so often inspiration hits, astounding, as if touched by angels or the gods themselves. The result ultimately that one liner that stirs yet unnamed emotions which, purely through the act of it's revelation and the fact that it came to exist alone, enlightens everyone that comprehend it's simplicity enabling the collective consciousness the ability to realize more possibility with even greater ease.

One of my favourite pass times, discovering beautiful ingenious code that brings with it wisdom and insight surpassing any amount of conventional knowledge or instruction you may consume in other ways. You may think these scarce but you will learn to know that they want to be discovered and cannot be concealed for long.

When I happen to discover one of these resulting from my own finger tips touching the appropriate keys in the correct sequence, as if channeled from somewhere external rather than the result of mental pros or some genius. On the contrary, I can't help but think: Why haven't I thought about it earlier? It's humbling when you come to think of it, theres probably an even simpler solution which you just haven't realized yet. =)

PSR-0 in one line

<?php

        /** add / at start if no \, replace \ with / and _ in CLASS NAME with / = PSR-0 */
        $file = preg_replace('/^(?=\w)|\\\|_(?=\w+$)/', DIRECTORY_SEPARATOR, $className);

More coming soon may this be inspiration to us all... keep your code small and the pandas happy.

[alganet]

I really like small code! Like the old PHP 5.2 days when I used str_replace for autoloading =D This looks great, and for a Regex (which tends to be write-only due to their illegibility) it's pretty readable.

[augustohp]

I think #8 fixes this, right!?

[nickl-]

@augustohp The added tests are a bonus but there are some features that is coming here like:

• Support for namespace/class aliases
• Interface for extendable caching strategies
• Adapters for easy pluggable/customizable discovery strategies.

The work has been done and is here somewhere... tx for raising attention.

Any additional thoughts? Something I have forgotten?

[augustohp]

@nickl- None whatsoever! 😄 I will create separate issues for each one so we can keep track of them. Othe than that, do you agree on closing this issue!? I am a 👍 for closing this one.