returning(...) ?

[Brian Candler]

On Wed, Sep 05, 2007 at 06:35:25AM +0100, Brian Candler wrote:
> To solve this, I am pondering along the following lines:
> 
> * Merb implements all these extension methods in a distinct namespace,
>   e.g. Hash.merb_from_xml (or perhaps, for class methods, Merb::Hash.from_xml)
> 
> * Merb's internal use of these constructs uses these distinct names
> 
> * If a user 'require's a specific library, then these get aliased to the
>   expected names, e.g. Hash.from_xml

I just noticed another mail saying there are now "supported plugins" in the
tree.

So I propose:

1. Move core_ext into a supported plugin.

Where Merb itself currently makes use of features within core_ext:

2. If it can be changed to use native Ruby instead, without making the code
   harder to maintain or significantly slower, then do that.

3. Otherwise, put the method in merb's own core_ext but with a private name,
   e.g. "merb_foo". The public core_ext will alias this to a more common
   name, e.g. "foo"

The core_ext plugin needs to have its own separate specs, so that Merb's own
specs prove that it works without the core_ext plugin.

This gives users of Merb three options:
- don't use core extensions
- use Merb's core extensions plugin
- use someone else's core extensions (e.g. ActiveSupport), which may be
  necessary in the case where an ORM depends on it (e.g. ActiveRecord)

Comments?

Brian.

P.S. I think the plugins directory should have a trunk/tags/branches
structure, so that when merb-x.x.x is released, a matching set of plugins
can also be tagged. Users can always choose to install a more recent version
of the plugin, but this is at their own risk.