Custom providers handling (0.0.4 or 0.0.5)
Maciej Piechotka
merb_global/providers/provider_name and be named
Merb::Global::Providers::ProviderName. It's not very well as it creates
strange assumptions about the location or naming.
Alternative approach would be:
a) Using a function which would return the module and register it under
proper name (or default if none argument given)
class MyCustomProvider
include Merb::Global::Provider(:my_custom_provider)
end
Pros: Allow custom naming (like :datamapper for DataMapper) or even
aliases.
Cons: Harder to implement. Surprising usage of constants. Where to put
the documentation?
b) Using a module which would automatically register the provider
class MyCustimProvider
include Merb::Global::Provider
end
Pros: Simple to implement - without even major changes to current code.
Easy to document
Cons: Only one name possible.
c) Other?
Personally [as developer] I prefer the simplicity of b). However as a
user I might prefer the flexibility of a).
The question of course is about the current modules:
a) Use the same mechanism only detecting if the current gem is present
Pros: Simple and consistent
Cons: May have bigger memory consumption
b) Use the same mechanism detecting if the current gem is present and
loading the library (dm, ar, yaml...) only on request
(If the detecting of installation of gem requires it's loading then load
all providers and load library [and throw exceptions] when needed)
Pros: Consistent and relatively memory-saving
Cons: Hard to implement (may require the anonymous classes in database
providers)
c) Fallback to current mechanism
Pros: Simple and memory savvy
Cons: Not very consistent
d) Other?
I think c) is consistent with KISS rule.
Regards