Parameter Finder Class

[judgej]

All the classes so far are defined using low-level parameters. There are many pre-defined sets of parameters that are names and tabulated. These include ellipsoids, datums, projections, and a few other settings. There are a core set that are often used, but the full range is vast, and not available in any one place (so far as I can see).

So when creating a new Ellipsoid, for example, it would be good just to be able to give it a name (e.g. "airy") and have the details looked up. Those details may be pre-defined in the plugin, may be in a database, may need a HTTP API lookup, may be registered locally by the application - all these sources need a common interface that these classes can use without having to know where the final source of those details is.

That interface could be injected into each class to help when constructing. Or perhaps injected into an object factory? Whichever way it works, creating new objects in this package needs to go through some instantiated object or class (that references a global /shudder/ of some sort) that knows where to look things up. Maybe it looks for a factory in its own namespace, so any third-party library can define that library if it wants to hook in. It is a method of hooking in that we are essentially looking for.

[judgej]

This could be implemented through namespaces: if each list of definitions is defined in a given namespace, as classes meeting a given interface, then named settings could be found using class_exists(). The disadvantage would be not being able to get lists of supported named settings groups like this, since you don't know, with an autoloader, what classes are available in a namespace until you try loading those classes.