Lazy services feature #42

Merged
merged 6 commits into from May 23, 2012

Conversation

Projects
None yet
3 participants
Contributor

l3pp4rd commented May 9, 2012

Implements a lazy service registry. Registered services are evaluated only during the first request all following requests will get the same instance of the service.

Looking at the code I noticed that _App usage is very limited and may be not useful practically. Maybe it can be removed?

Contributor

nickl- commented May 11, 2012

By _request_ I think you mean call i.o.w. Registered services are evaluated on the first call for the service and the same instance will be returned on every subsequent call in the same request. There will still always be one initialization occurring for every statically referenced unique service per new request.

Unless it has changed or I might be mistaken but this is what the manual says about Using static variables.

I may add my +1 if we can get this cleared up and the documentation reflects the same.

Collaborator

chriso commented May 17, 2012

The App class is used to hold scope between route callbacks

<?php
respond('*', function ($request, $response, $app) {
    $app->db = new SomeDBClass();
});

//Later

respond('/', function ($request, $response, $app) {
    $app->db->query(...); //etc
});

I like the concept of lazy initialisation but I'd only consider adding this functionality if it were a part of the App class as $app->service(..) rather than a global function.

You could even lookup and initialise the service using __get rather than needing to call $app->service('db');

<?php

respond('*', function ($request, $response, $app) {
    $app->register('db', function () {
        return new someDBClass();
    });
});

respond('/', function ($request, $response, $app) {
    $app->db->query(...);
});
Contributor

l3pp4rd commented May 17, 2012

ah, I see, somehow thought, that registering helpers to $app is not practical using respond in global scope, I'll update the code, this way it even become more clear about $app usage purpose from documentation

Contributor

nickl- commented May 17, 2012

Keep up the good work!

Contributor

l3pp4rd commented May 17, 2012

@chriso this should be better, scope is limited

Contributor

l3pp4rd commented May 17, 2012

the App in its structure could store parameters too, but I personally think this would expose the posibility to change logic on runtime. If services are registered using specific user parameters in a limited scope, this is a better practice in general

Collaborator

chriso commented May 23, 2012

Looks good, thanks

chriso added a commit that referenced this pull request May 23, 2012

@chriso chriso merged commit f376f65 into klein:master May 23, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment