Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find a better name for "InjectedAPI" #11

Open
donquixote opened this issue Jul 15, 2013 · 3 comments
Open

Find a better name for "InjectedAPI" #11

donquixote opened this issue Jul 15, 2013 · 3 comments

Comments

@donquixote
Copy link
Owner

"InjectedAPI" is a "pattern" I have used a number of times in different projects, but I seriously have no idea if there is anyone else in the world doing that, and what would be the official name.

The idea is an object being passed around to different places to collect information, or to do something with that information.

@donquixote
Copy link
Owner Author

Example 1: Class loading/finding.

During class finding, the class finder/loader and the registered namespace plugins have the job to tell the InjectedAPI object about any file that may contain the class we are looking for. If for some candidate the InjectedAPI object returns TRUE, it has to stop. Otherwise, it has to continue and look for further candidates.

The InjectedAPI object, depending on its implementation, may simply collect the file candidates, or it may check whether the file exists, include it, and then check whether the class was successfully defined.
It can then decide (via return value of TRUE or FALSE) whether the class finder / plugins should continue looking, or stop.

In the original Drupal module (xautoload), all class loading and class finding was done with this InjectedAPI thingie.

The nice thing about that was that the plugins and the loader itself would never hit the filesystem. So, every "class_exists()" and "include" could be simulated with a mocked InjectedAPI object. So we could unit-test the class loader without any fixture files. Yeah!

In Krautoload, at some point I decided to remove this layer of abstraction during normal class loading, to avoid the tiny but measurable overhead.

So, now every plugin has a pluginLoadClass() with hardcoded/inline filesystem operations, and a pluginFindFile() that is filesystem-agnostic and only tells the $api argument about whatever it finds.

@donquixote
Copy link
Owner Author

Example 2: Class discovery.

During class discovery, the namespace plugins registered at specific base namespaces and base directories have the job to tell the InjectedAPI object about any file that could contain a class within the searched namespaces.

The InjectedAPI, depending on its implementation, may simply collect those class and file candidates in a huge array, or it may parse each file, analyse the annotations, etc.

@donquixote
Copy link
Owner Author

Example 3: Namespace inspection.

During namespace inspection (which atm is only used for class discovery), the plugins' job is to tell the InjectedAPI object about any directory that could contain classes within the specified namespace.

The InjectedAPI object, depending on its implementation, may simply collect these directories in an array, or it may actually scan the directories for classes - either flat or recursive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant