returning(...) ?

[Stephen Caudill]

On Sep 5, 2007, at 3:36 AM, Brian Candler wrote:

> 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?

I think this is extreme.  I appreciate the sentiment, but as a  
committer, I'd still like to have a library at hand to provide  
conveniences.  I'm not opposed to that library living in an insular  
namespace

> 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.

Sounds like a good idea.